Tese - Ricardo H. B. Azoubel PDF

UNIVERSIDADE FEDERAL DO MARANHO
CENTRO DE CINCIAS EXATAS E TECNOLGICAS

CURSO DE PS-GRADUAO EM ENGENHARIA DE ELETRICIDADE
CINCIA DA COMPUTAO

Ricardo Henrique Bezerra Azoubel

UMA PLATAFORMA DE TESTES COM SERVIOS DIFERENCIADOS
PARA MODELAGEM DE TRFEGO DE VOZ SOBRE IP: anlises de
desempenho e de impacto

So Luis
2004

ii

UNIVERSIDADE FEDERAL DO MARANHO
CENTRO DE CINCIAS EXATAS E TECNOLGICAS
CURSO DE PS-GRADUAO EM ENGENHARIA DE ELETRICIDADE
CINCIA DA COMPUTAO

UMA PLATAFORMA DE TESTES COM SERVIOS DIFERENCIADOS
PARA MODELAGEM DE TRFEGO DE VOZ SOBRE IP: anlises de
desempenho e de impacto

Dissertao submetida Universidade Federal do
Maranho, como parte dos requisitos para a obteno do
grau de mestre em Cincia da Computao.


Prof. Dr. Zair Abdelouahab
Orientador

So Luis
2004

iii

UMA PLATAFORMA DE TESTES COM SERVIOS
DIFERENCIADOS PARA MODELAGEM DE TRFEGO DE VOZ
SOBRE IP: anlises de desempenho e de impacto.


Esta Dissertao, por meio da comisso julgadora dos trabalhos de defesa de
Dissertao de Mestrado, foi julgada adequada para a obteno do ttulo de Mestre em
Engenharia Eltrica, rea de Concentrao Cincia da Computao, e aprovada na sua
forma final pelo Programa de Ps-Graduao em Engenharia Eltrica da Universidade
Federal do Maranho, em sesso pblica realizada em / / .

Presidente

_____________________________________
Prof. Dr. Zair Abdelouahab
(Orientador)

1
o
Examinador

_____________________________________
Prof. Dr. Djamel Sadok

2
o
Examinador

_____________________________________
Prof. Dr. Edson Nascimento

iv

Dedicatria

A meu Pai, Ded Azoubel, de qualquer forma e
nalguma forma ...... feliz. Muito feliz, com certeza.
A Vadinho, meu amado e eterno filhote.

v

Agradecimentos
Sobretudo a Deus criador, pela sade e possibilidade de realizar este trabalho.
A minha me, Lourdinha, pelo imensurvel amor e ajuda dados em toda minha existncia.
A minha esposa e eterna companheira, Sheylinha, pela pacincia, compreenso e amor
despejados durante o trabalho.
Aos meus irmos Drey, Anita (mamainha), Uziel, Tadeu, Lcia e Z Cludio, assim
como aos meus cunhados e sobrinhos, pelo apoio e incentivo dirios.
Ao professor Zair, pela disponibilidade, orientao e incentivo, importantes para o
desenvolvimento desta dissertao.
Ao professor Carlos Brando, pela orientao tcnica e incentivo, essenciais para a
realizao deste trabalho.
Ao amigo Wagner Elvio, pelo grande apoio na construo da plataforma de testes.
A Alcides, Ismael, professora Maria da Guia e demais amigos alunos do programa de
ps-graduao do departamento de energia eltrica da UFMA.

vi

Resumo
Este trabalho apresenta uma plataforma de testes (testbed) sem custos, construda num
ambiente controlado composto por microcomputadores e softwares livres. Implementa-se,
em tal plataforma, o modelo de servio diferenciado (DiffServ), com encaminhamento
expresso (PHB EF). Prope-se, fundamentalmente, a partir da obteno das principais
mtricas de QoS (atraso, jitter, perda e vazo), a anlise do desempenho de trfego
caracterstico de voz, quando submetido a testes experimentais em vrios cenrios e
condies. Inicialmente, num ambiente capaz de diferenciar trfego, modelam-se fluxos
gerados por codificadores/decodificadores de voz padronizados (G.711 e G.726), em que se
varia o tamanho dos pacotes e a quantidade de fluxos agregados, em cenrios com e sem
QoS. Compara-se, em seguida, o comportamento de fluxos gerados por fontes atividade-
silncio (ON-OFF) e contnuas (CBR). Pode-se perceber nesse estudo o quanto a variao
do tamanho dos pacotes impacta no desempenho dos pacotes mais prioritrios. Realiza-se,
na seqncia, uma anlise especfica do fator agregao em fluxos gerados por fontes ON-
OFF e observa-se a atuao do princpio bsico do modelo DiffServ, onde fluxos agregados
recebem tratamento diferenciado. Estuda-se, por fim, atravs da utilizao de protocolos de
transporte (UDP e TCP) e de fluxos elsticos do tipo FTP, o quanto o trfego de melhor
esforo impacta no desempenho de fluxos modelados de voz.

Palavras-chaves: Servios Diferenciados (DiffServ), Qualidade de Servio e Voz sobre IP
(VoIP).

vii

Abstract
This work presents a platform of tests (testbed) inexpensive, constructed in a controlled
environment composed by microcomputers and free softwares. It is implemented, in such
platform, the differentiated service model (DiffServ), with expedited forwarding (PHB EF).
It is basically considered, from the collection of metrics main of QoS (delay, jitter, loss and
throughtput), the performance analysis of voice characteristic traffics, when submitted to
experimental tests in some scenes and conditions. Initially, in an environment capable to
differentiate traffics, flows generated by standardized voice coder/decoder (G.711 and
G.726) are modeled, in which the packets size and the amount of aggregate flows are
varied, in scenes with and without QoS. It is compared, after that, the behavior of flows
generated by activity-silence (ON-OFF) and continuous (CBR) sources. Can be perceived in
this study how much the packets size variation influence in the performance of the most
priority packets. It is carried, in the sequence, a specific analysis of the aggregation factor in
flows generated by ON-OFF sources, in which can be observed the action of the basic
principle of the model DiffServ, where aggregate flows receive differentiated treatment. It is
studied, finally, through the use of transport protocols (UDP and TCP) and of elastic flows
of FTP type, how much the best effort traffic confuses the performance of voice modeled
flows.

Keywords: Differentiated Services, Quality of Service and Voice over IP (VoIP).

viii

Sumrio
1. INTRODUO........................................................................................................1
1.1 OBJETIVOS DO TRABALHO ...........................................................................................................3
1.2 ORGANIZAO DOS TPICOS .......................................................................................................4
1.3 CONCLUSO DO CAPTULO...........................................................................................................4
2. FUNDAMENTOS BSICOS DE QOS...................................................................5
2.1 O PORQU DA QUALIDADE DE SERVIO.......................................................................................5
2.2 MLTIPLAS DEFINIES ..............................................................................................................7
2.3 O MELHOR ESFORO..................................................................................................................7
2.4 CLASSIFICAO DAS APLICAES................................................................................................9
2.4.1 Aplicaes Elsticas ...........................................................................................................9
2.4.2 Aplicaes de Tempo Real ................................................................................................ 10
2.5 MODELOS DE QOS..................................................................................................................... 11
2.5.1 Servio Integrado.............................................................................................................. 11
2.5.1.1 Servio Garantido (Guaranteed Service)...................................................................................... 13
2.5.1.2 Servio de Carga Controlada (Controlled Load Service) .............................................................. 13
2.5.1.3 Componentes para implementao do IntServ.............................................................................. 13
2.5.1.4 Crticas ao modelo IntServ .......................................................................................................... 15
2.5.2 Servio Diferenciado ........................................................................................................ 16
2.5.3 Redes IntServ sobre DiffServ............................................................................................. 18
2.6 MTRICAS DA QUALIDADE DE SERVIO...................................................................................... 19
2.6.1 Atraso............................................................................................................................... 20
2.6.2 Variao do atraso entre pacotes (jitter)........................................................................... 20
2.6.3 Largura de banda e Vazo ................................................................................................ 22
2.7 CONCLUSO DO CAPTULO......................................................................................................... 23
3. SERVIOS DIFERENCIADOS (DIFFSERV) .....................................................24
3.1 CONDICIONAMENTO DE TRFEGO NO MODELO DIFFSERV......................................................... 24
3.1.1 Funes de condicionamento de trfego ........................................................................... 25
3.1.2 Mecanismos de medio e policiamento de trfego........................................................... 26
3.2 ACORDO DE NVEL DE SERVIO (SLA) ....................................................................................... 28
3.3 PER-HOP BEHAVIOR (PHB)....................................................................................................... 30
3.3.1 Encaminhamento Assegurado (PHB AF)........................................................................... 31
3.3.2 Encaminhamento Expresso (PHB EF)............................................................................... 33
3.4 DIFFSERV EM AMBIENTE LINUX................................................................................................. 34
3.4.1 Disciplinas de escalonamento........................................................................................... 35
3.5 VOZ SOBRE IP COMO UMA APLICAO DIFERENCIADA .............................................................. 39
4. O AMBIENTE DE TESTES..................................................................................45
4.1 TOPOLOGIA DA REDE ................................................................................................................. 45
4.2 METODOLOGIA ADOTADA.......................................................................................................... 47
4.2.1 Aspectos gerais................................................................................................................. 47
4.2.2 Sincronizao do tempo.................................................................................................... 49
4.2.3 Ferramentas de software................................................................................................... 50
5. MODELAGEM DE VOCODERS DE UDIO.....................................................53
5.1 APLICAO DA DISCIPLINA PRI O................................................................................................ 59
5.1.1 Estudo do delay ................................................................................................................ 59
5.1.2 Estudo do jitter ................................................................................................................. 62
5.1.3 Estudo das taxas de perdas de pacotes e de vazo............................................................. 63
5.1.4 A disciplina prio num ambiente de sobrecarga.................................................................. 65
5.2 APLICAO DA DISCIPLINA BFI FO.............................................................................................. 67

ix

5.2.1 Estudo do delay ................................................................................................................ 67
5.2.2 Estudo do jitter ................................................................................................................. 69
5.2.3 Estudo da taxa de perda de pacotes .................................................................................. 70
6. ESTUDO DA CONTINUIDADE DOS FLUXOS .................................................73
6.1 DESEMPENHO DE FONTES GERADORAS DISTINTAS ...................................................................... 73
6.1.1 Estudo do delay ................................................................................................................ 74
6.1.2 Estudo do jitter ................................................................................................................. 77
6.1.3 Estudo da taxa de perda de pacotes .................................................................................. 79
6.2 AGREGAO ON-OFF DE FLUXOS PRIORITRIOS...................................................................... 80
7. IMPACTOS DO TRFEGO DE FUNDO............................................................84
7.1 PRIMEIRA ETAPA........................................................................................................................ 84
7.1.1 Estudo do delay ................................................................................................................ 86
7.1.2 Estudo do jitter ................................................................................................................. 87
7.1.3 Estudo das taxas de perda de pacotes e de vazo.............................................................. 89
7.1.4 Estudo da agregao de voz (uso de apenas 1 fluxo prioritrio)........................................ 91
7.2 SEGUNDA ETAPA......................................................................................................................... 93
8. CONCLUSO......................................................................................................100
9. REFERNCIAS BIBLIOGRFICAS ................................................................104

x

Lista de Figuras
Figura 2-1 O original byte TOS do IPv4................................................................................................ 17
Figura 2-2 Campo DS do cabealho IPv4, definido pela RFC 2474. ...................................................... 18
Figura 2-3 Modelo que combina as arquiteturas integrada e diferenciada. ............................................. 19
Figura 2-4 Conceito de atraso em um sentido (OWD). .......................................................................... 20
Figura 2-5 Ocorrncia de variaes de delays entre pacotes. .................................................................. 21
Figura 2-6 Atuao do buffer na estabilizao dos fluxos com jitter....................................................... 22
Figura 3-1 Elementos de condicionamento de trfego.................................................................................. 24
Figura 3-2 Domnio de Servios Diferenciados........................................................................................... 26
Figura 3-3 Mtodo do Balde de Fichas .................................................................................................. 27
Figura 3-4 SLA esttico........................................................................................................................ 30
Figura 3-5 SLA dinmico, com uso de BBs........................................................................................... 30
Figura 3-6 Princpio bsico de controle de trfego no Linux ......................................................................... 34
Figura 3-7 Exemplo de uma simples disciplina de servio no Linux, com vrias classes. .................................. 35
Figura 3-8 Estrutura bsica da disciplina prio no Linux........................................................................ 39
Figura 3-9 Classificao da viabilidade de operao das aplicaes de voz, segundo o ITU-T. .......................... 42
Figura 4-1 Topologia da rede................................................................................................................... 46
Figura 5-1 Valor mdio de delay.............................................................................................................. 54
Figura 5-2 Valor mdio de jitter............................................................................................................... 55
Figura 5-3 Taxa de perda de pacotes. ........................................................................................................ 56
Figura 5-4 Taxa de vazo alcanada. ..................................................................................................... 57
Figura 5-5 Delay de voz com a disciplina prio. ..................................................................................... 60
Figura 5-6 Delay do trfego de perturbao com a disciplina prio. ........................................................ 61
Figura 5-7 Jitter com a disciplina prio................................................................................................... 63
Figura 5-8 Taxa de descarte de pacotes com a disciplina prio................................................................ 64
Figura 5-9 Taxa de vazo alcanada, com a disciplina prio................................................................ 65
Figura 5-10 Delay com a disciplina prio. Cenrio de sobrecarga. ....................................................... 66
Figura 5-11 Jitter (a), taxas de perda (b) e de vazo alcanada (c), com prio. Cenrio de sobrecarga.67
Figura 5-12 (a) Delay com bfifo; (b) Comparao de delays entre as disciplinas prio e bfifo.................. 68
Figura 5-13 (a) Jitter com bfifo; (b) Comparao de jitters entre as disciplinas prio e bfifo.................... 70
Figura 5-14 (a) Taxa de perdas com bfifo; (b) Comparao de taxas de perdas entre as disciplinas prio e
bfifo ................................................................................................................................... 71
Figura 6-1 Delay mdio dos fluxos de voz. ............................................................................................ 75
Figura 6-2 Delay mdio do trfego de fundo (BE). ...................................................................................... 76
Figura 6-3 Jitter mdio do trfego de voz. ............................................................................................. 78
Figura 6-4 Taxa mdia de descarte de pacotes do trfego de voz............................................................ 79
Figura 6-5 Estudo da agregao com fluxos ON-OFF Valores mdios de delay. ................................. 81
Figura 6-6 Estudo da agregao com fluxos ON-OFF Valores mdios de jitter. .................................. 82
Figura 6-7 Estudo da agregao com fluxos ON-OFF Taxas mdias de perda de pacotes. ................... 82
Figura 7-1 Impacto do trfego BE Valores mdios de delay de voz. .................................................... 86
Figura 7-2 Impacto do trfego BE Valores mdios de jitter de voz...................................................... 88
Figura 7-3 Impacto do trfego BE Valores mdios de perda de pacotes prioritrios. ........................... 89
Figura 7-4 Impacto do trfego BE Taxas mdias de vazo alcanada de pacotes prioritrios. .......... 90
Figura 7-5 Trfego BE (a) Taxa de perda de pacotes; (b) Taxa de vazo alcanada. ........................ 90
Figura 7-6 Impacto do trfego de fundo (estudo da agregao de voz) - Valores mdios de delay. ...................... 92
Figura 7-7 Impacto do trfego de fundo (estudo da agregao de voz) - Valores mdios de jitter. ....................... 92
Figura 7-8 Impacto do trfego de fundo (estudo da agregao de voz) - Taxas mdias de perda de pacotes. ......... 93
Figura 7-9 Delay mdio do trfego de voz. ............................................................................................ 95
Figura 7-10 Jitter mdio do trfego de voz. ........................................................................................... 95
Figura 7-11 Seqncias da vazo de melhor esforo. ............................................................................. 96
Figura 7-12 Taxa mdia de perda de pacotes dos trfegos de voz e de BE.............................................. 97
Figura 7-13 Taxa mdia de vazo alcanada dos trfegos de voz e de BE........................................... 98

xi

Lista de Tabelas
Tabela 3-1 Cdigos AF para classe de servio e nvel de precedncia .................................................... 32
Tabela 3-2 Valores DSCP definidos pela RFC 2597.............................................................................. 32
Tabela 5-1 Vazo agregada por vocoder..................................................................................................... 58
Tabela 5-2 Reservas de banda no roteador interno do domnio DS. ....................................................... 58
Tabela 5-3 Atrasos de gerao de pacotes............................................................................................... 60
Tabela 5-4 Reservas de banda no roteador interno do domnio DS Cenrio de sobrecarga. ................. 66
Tabela 5-5 Razo entre pacotes EF e BE gerados na rede. ..................................................................... 69
Tabela 6-1 Planejamento do estudo....................................................................................................... 74
Tabela 6-2 Clculo de tempo para gerao de pacotes, com agregado de voz do tipo ON-OFF............... 77
Tabela 6-3 Clculo de tempo para gerao de pacotes, com agregado de voz do tipo CBR..................... 77
Tabela 6-4 Percentuais de pacotes CBR e ON-OFF encaminhados na rede. ........................................... 79
Tabela 6-5 Estudo da agregao ON-OFF Planejamento............................................................................ 81
Tabela 7-1 Planejamento da 1
a
etapa Taxas de gerao usadas nos protocolos TCP e UDP em BE e em
Voz ..................................................................................................................................... 85

xii

Lista de Abreviaturas
ADPCM Adaptive Differential Pulse Code Modulation
AF Assured Forwarding
BA Behavior Aggregate
BB Bandwidth Broker
BE Best Effort
CBQ Class-Based Queuing
CBR Constant Bit Rate
COPS Commom Open Policy Service
DSCP DiffServ Code Point
DSP Digital Signal Processor
DWDM Dense Wavelength Division Multiplexing
EF Expedited Forwarding
FEC Forward Error Correction
FIFO First In First Out
FTP File Transfer Protocol
GPS Global Positioning System
GRED Generic Random Early Detection
HTTP Hipertext Transfer Protocol
IETF Internet Engineering Task Force
IPDV Instantaneous Packet Delay Variation
IPPM IP Performance Metrics Working Group
ISO International Standardization Organization
ISP Internet Service Provider
ITU-T International Telecommunications Union - Telecommunication Standardization
Sector
MOS Mean Opinion Score
MPEG Moving Picture Experts Group
MTU Maximum Transfer Unit
NFS Network File System
NTP Network Time Protocol
OWD One-Way Delay
P2P Peer-to-Peer
PCM Pulse Code Modulation
PHB Per-Hop Behavior
PQ Priority Queuing
QDISC Queue Discipline
QoS Quality of Service
RED Random Early Detection

xiii

RFC Request for Comments
RSVP Resource Reservation Protocol
RTP Real Time Transport Protocol
SFQ Stochastic Fairness Queuing
SLA Service Level Agreement
SLS Service Level Specifications
TC Traffic Class
TCP Transmission Control Protocol
ToS Type of Service
UDP User Datagram Protocol
VoIP Voice over IP

1. Introduo
O surgimento de tipos de aplicaes, como multimdia, voz sobre IP (VoIP),
educao distncia e vdeo-conferncia, por exemplo, exige o uso de tcnicas e
mecanismos avanados para atender s necessidades dos usurios. Por tratar-se de servios
que ocupam muito os recursos de uma rede, exigem, inclusive, controles rgidos para uma
comunicao mnima e satisfatria. No mais, junta-se isso ao fato de que a Internet, j h
algum tempo no mais restrita ao meio acadmico, um ambiente oportuno para o uso de
tais aplicaes, dadas sua escalabilidade e abrangncia mundial. Tem-se, portanto, o
objetivo maior de se disponibilizar sistemas crticos em ambientes de rede pblicos,
concorrentes e compartilhados (caso da Internet).
Vem-se, com a rede mundial, tendncias crescentes na necessidade de
convergncia das redes de computadores numa infra-estrutura possivelmente nica, capaz
de integrar servios de dados, voz e at vdeo. Isto desafiador, considerando tratar-se de
uma rede IP construda originalmente para prover apenas servios tradicionais, de melhor
esforo (Best Effort), sem garantias de qualidade de servio (QoS). Desta forma, para que
haja eficincia na transmisso dos dados e satisfao dos usurios, presume-se que as redes
no mais devam tratar as aplicaes com os mesmos pesos, mas, sim, de formas reservada
ou diferenciada, de acordo com o grau de tolerncia e os requisitos mtricos (atrasos,
perdas, vazo) de cada uma delas. Pode-se afirmar ento que aplicaes de tempo real
(VoIP, por exemplo) no funcionam eficientemente numa rede sem QoS (ainda mais se esta
estiver carregada), cujos pacotes so manipulados com os mesmos requisitos aos de uma
aplicao no sensvel ao tempo (FTP e e-mail, por exemplo).
Qualidade de servio em redes IP , portanto, um aspecto fundamental para o
desempenho fim-a-fim das aplicaes, sendo crucial o entendimento de seus princpios,
parmetros, mecanismos, algoritmos e protocolos, desenvolvidos, testados e utilizados para
a obteno de resultados favorveis.
De uma forma geral, o objetivo maior das pesquisas na rea de QoS a
maximizao da utilizao de redes locais ou remotas, atravs do uso mais eficiente de seus
recursos e de um melhor controle dos nveis de congestionamento do trfego, adicionando

2

alguma inteligncia rede com o fim de reservar recursos ou diferenciar pacotes de
dados, de acordo com os requisitos pr-determinados. Em redes IP, mais especificamente,
os objetivos da qualidade de servio so traduzidos em desafios, resumidos a seguir,
segundo [2]:
O IP, por default, como protocolo, no tem garantia de qualidade de servio
e;
Com a Internet, a base instalada do IP tornou-se mundial, o que mantm
invivel a mudana de protocolo.
O primeiro desafio resume-se na simplicidade do protocolo de rede, projetado
originalmente para tratar as aplicaes sem distino, por melhor esforo. J o segundo,
obriga adequar-se ao novo paradigma, sem mudanas significativas no protocolo. Mesmo
frente s inadequaes e fragilidades do IP, pode-se afirmar que disponibilizar QoS nesse
tipo de rede no utopia, desde que os protocolos, as arquiteturas, os algoritmos e os
mecanismos sejam adequadamente aplicados e mantidos. O IETF (Internet Engineering
Task Force) vem mantendo, desde 1994, pesquisas para prover qualidade de servio em
redes de computadores, sendo que, para isso, criou grupos de trabalhos responsveis em
estabelecer padres e tecnologias, como por exemplo: as arquiteturas de servios integrados
(IntServ)[12] e diferenciados[32], cujas atividades foram encerradas em maio/2001 e
fevereiro/2003, respectivamente, e o protocolo RSVP, principal componente dos servios
IntServ.
Associados pesquisa do desempenho de aplicaes multimdia em ambientes
com qualidade de servio, mais especificamente com servios diferenciados (DiffServ) [1],
esto alguns trabalhos de simulao disponibilizados pelo Grupo de Teleinformtica e
Automao (GTA) da Universidade Federal do Rio de Janeiro, como [33], [56] e [57]. Em
[58], Anurag Tyagi estuda, tambm atravs de simulaes, por meio da ferramenta NS-
2[61], o desempenho de trfego gerado por diferentes padres de vocodecs de udio,
usados para manipular sinais de voz. J em [59], Kos usa, outra vez, simulao para avaliar
o comportamento de uma rede diferenciada com aplicaes com distintos nveis de
sensibilidades, como HTTP, FTP, vdeoconferncia e voz sobre IP. Por fim, em [60], o
mesmo Kos compara o desempenho de aplicaes VoIP numa rede com DiffServ,

3

utilizando enfileiramentos dos tipos prioritrio (priority queuing) e FIFO (First In First
Out) numa rede simulada.
1.1 Objetivos do trabalho
De uma forma bem sucinta, este trabalho tem como finalidade avaliar, atravs
de uma srie de experimentos e medies, os nveis de efetividade dos servios
diferenciados (DiffServ), tomando como base uma plataforma de testes (testbed) composta
por hardwares de baixo custo (microcomputadores PC) e por softwares de cdigo aberto.
Tal avaliao realizada a partir de diversos cenrios, que so:
- Caracterizao de fluxos gerados por codificadores/decodificadores de voz
(VOCODERS) distintos, com a variao do tamanho dos pacotes e da
quantidade de fluxos agregados;
- Modelagem de fluxos gerados tanto por fontes contnuas (CBR) como por
fontes do tipo atividade-silncio (ON-OFF) e;
- Gerao de trfego de melhor esforo em cima da variao de seus
protocolos de transporte (UDP e TCP) e do uso de sesses FTP.
Em outras palavras, objetiva-se investigar quais modelagens de vocoders podem
apresentar melhor e pior desempenhos, em ambientes com e sem qualidade de servio.
Pretende-se tambm avaliar, num ambiente com priorizao de trfego, qual o tipo de
fonte de trfego (CBR ou ON-OFF) que alcana os melhores resultados. Por fim, procura-
se perscrutar quais impactos o trfego de fundo pode exercer sobre fluxos modelados de
voz.
De uma forma mais especfica, o trabalho tem a inteno no s de investigar e
observar, mas, principalmente, de interpretar e justificar, a partir das variantes ambientais
aplicadas na rede, as tendncias comportamentais das mtricas de QoS (atrasos, jitters e
taxas de descarte de pacotes e de vazo). Tais medidas referem-se tanto ao trfego de voz
quanto aos fluxos de melhor esforo. Estudos de agregao de fluxos de voz tambm
constituem os objetivos especficos da dissertao.

4

1.2 Organizao dos tpicos
O texto est organizado com o Captulo 2 apresentando uma fundamentao
terica sobre qualidade de servio. O Captulo 3 discute aspectos importantes do modelo
diferenciado, como condicionamento de trfego e o conceito de comportamentos por n, e
aborda o servio no ambiente Linux. O Captulo 4 mostra o ambiente de testes adotado,
com a apresentao da topologia de rede, dos mtodos e das ferramentas utilizadas. O
Captulo 5 confirma a capacidade do ambiente em diferenciar trfego e apresenta estudo da
modelagem de vocoders em ambientes com e sem servio diferenciado. O Captulo 6 estuda
a modelagem de trfego de voz, gerado por fontes contnuas e de atividade-silncio. O
Captulo 7 avalia os impactos causados pela variao do trfego de melhor esforo no
desempenho de fluxos modelados de voz. Finalmente, o Captulo 8 conclui o trabalho,
destacando as contribuies e relacionando trabalhos futuros.
1.3 Concluso do captulo
O captulo inicial se encarrega apenas em apresentar as primeiras consideraes
sobre o tema, introduzindo, basicamente, os desafios da rea de qualidade de servio e os
objetivos do trabalho. A organizao do texto tambm mostrada.

5

2. Fundamentos Bsicos de QoS
Sero apresentadas a seguir algumas abordagens importantes sobre qualidade de
servio, necessrias para a consistncia da fundamentao terica do trabalho. Sero
discutidos vrios aspectos, como a necessidade de QoS nas redes de computadores, os
modelos propostos e as mtricas essenciais para estudo.
2.1 O porqu da Qualidade de Servio
A Internet tem evoludo de tal forma que praticamente todos os tipos de
aplicaes, como os sistemas crticos de voz e de vdeo, precisam convergir para aquele
ambiente. Como j descrito no captulo anterior, a Internet (ou o protocolo IP), por si s,
no um meio propcio para as exigncias de recursos que essas aplicaes demandam.
Elas tm, geralmente, como requisitos, a baixa latncia, pequenos nveis de perdas de
pacotes e um certo grau de desempenho.
A resposta pode estar ento em fazer com que esses sistemas tenham garantias
de ser executados, atendendo a seus requisitos de uma maneira satisfatria, sem necessidade
de elevar-se a quantidade de recursos
1
da rede. De uma forma geral, prover qualidade de
servio numa rede como a IP, inadequada pela imprevisibilidade de resultados, pode ser
justificado pela alternativa de poder-se aumentar a eficincia dessa rede sem ter-se que
pagar mais por isso.
Na verdade, de acordo com a justificativa acima e a partir da idia posta em [4],
tem-se a seguinte discusso: com as novas tecnologias atualmente sendo disponibilizadas
(fibras e DWDM, por exemplo), geralmente v-se abundncia e o barateamento de recursos
de rede (como largura de banda). Com isso, no se faz necessrio ter-se qualidade de
servio. Por outro lado, mesmo com o aumento substancial dos mesmos recursos (toma-se
novamente a largura de banda como exemplo), sempre vo existir aplicaes capazes de
consumi-las e, desta forma, haver, sempre, a necessidade de QoS na rede, conduzindo
opinio de que aumento na largura de banda no vai eliminar a necessidade de QoS. Sobre
esta discusso, [3] abre a questo do gerenciamento de rede com QoS contra o aumento na

6

capacidade de recursos, com o segundo argumento podendo ser, muitas das vezes: i) mais
barato, considerando-se a economia de tempo e a pouca necessidade de capacitao dos
tcnicos de suporte e ii) mais preciso, j que se pode estimar quanto gastar na compra de
recursos. No entanto, nem sempre aumentar a capacidade da rede significa resolver os
problemas do meio, quando ento h a necessidade de inteligncia para um bom
gerenciamento dos recursos, justificando assim o uso de QoS. Para aplicaes VoIP, por
exemplo, o simples aumento na largura de banda pode no ser a soluo, j que esse tipo de
aplicao apresenta outros requisitos (o de tempo, por exemplo) mais crticos e
significativos para o alcance de bons resultados.
No possvel rede dar algo que ela no tenha. Ou seja, QoS no pode criar
largura de banda inexistente, apesar da disponibilidade desse recurso ser um ponto
importante e um bom comeo para se garantir uma execuo satisfatria das aplicaes. A
qualidade de servio apenas tenta gerenciar a largura de banda, de acordo com a demanda
das aplicaes e as configuraes da rede, melhorando seu desempenho e garantindo a
alocao de recursos aos fluxos de dados.
Em cima disto, importante esclarecer que, alm da idia exposta acima, de que
QoS no cria recursos, ainda h, segundo [3], algumas outras restries que ainda persistem
em torno do assunto, como por exemplo: i) os mecanismos de QoS atuam
preferencialmente em situaes de conteno da rede, sendo irrelevantes nos casos de
ociosidade; ii) QoS elitista e injusta, na medida em que d prioridade a algumas classes
em detrimento de outras, forando os usurios a pagarem mais caro para sentir que suas
aplicaes so mais eficientes; e iii) QoS no consegue compensar imperfeies da rede,
como maus projetos e situaes drsticas de congestionamento.
O certo que, apesar de tudo isso, mas frente aos desafios impostos pela
necessidade de integrao de aplicaes na Internet, QoS tema de extrema importncia e
utilidade, que alcana avanadas pesquisas em todo mundo e com alguns produtos
(padronizados por organismos internacionais) j disponveis no mercado. Esses so
aspectos mais do que suficientes para justificar o porqu da qualidade de servio nas atuais
redes de computadores.

1
Por recursos entendem-se, por exemplo, largura de banda no meio e memrias e processadores nos
roteadores.

7

2.2 Mltiplas definies
O termo QoS pode assumir vrias conotaes, dependendo de onde poder ser
aplicado. Segundo a ISO (International Standardization Organization), QoS o efeito do
desempenho de um servio para medir nveis de satisfao dos usurios daquele servio[8].
J segundo [9], QoS serve tanto para definir o desempenho da rede em relao s
necessidades das aplicaes, como para possibilitar a essas redes garantias de desempenho.
Outra definio pode ser aproveitada a partir de [10], em que se tem QoS como
a capacidade de um elemento de rede ter algum nvel de garantia de que requisitos de
trfego e servios possam ser satisfeitos, com a rede provendo formas de encaminhamento
de dados de maneira consistente e previsvel. J [11] se aproxima desta definio, mas
explica que o termo elemento de rede pode ser uma aplicao, um hospedeiro (host), um
roteador ou outro dispositivo.
De uma forma sucinta, e aproveitando as definies aqui utilizadas, pode-se
dizer que qualidade de servio seja a capacidade da rede de prover melhores servios a
trfego selecionado (prioritrio), sobre vrias tecnologias de acesso, como, por exemplo,
Ethernet, Frame Relay e ATM. No mais, tem como objetivo bsico disponibilizar os
recursos necessrios aos pacotes de dados, de acordo com os nveis de relevncia de cada
servio, oferecendo assim maior garantia s aplicaes e maior satisfao aos usurios da
rede.
2.3 O Melhor Esforo
Redes IP so geralmente descritas como redes de melhor esforo (best effort).
Isto se refere ao modelo no qual a rede no diferencia o tratamento dos servios que nela
trafegam, sendo todos os pacotes manipulados de uma mesma forma, com uma mesma
prioridade.
A partir da concepo do protocolo IP, sabe-se que este no garante entregar
os pacotes num tempo mnimo necessrio para as aplicaes nem tampouco entreg-los no
seu destino. Isto quer dizer que deve existir um esforo considervel dos elementos de
conectividade, geralmente roteadores, em cumprir com tais entregas. Ou seja, a rede

8

encarrega-se de liberar todos os pacotes to rapidamente quanto possvel, mas sem
garantias de manter a qualidade dos servios, sendo constantemente incapaz de tomar
medidas preventivas ou corretivas que possam manter tal qualidade em um patamar
satisfatrio para a maioria das aplicaes. Alm disso, dado que o trfego de dados
imprevisvel e em rajadas[5], h os problemas de congestionamentos, onde, por representar
o esgotamento dos recursos disponveis, pode provocar perdas ou atrasos dos pacotes. O
resultado de tal escassez uma sensvel degradao da qualidade percebida pelos usurios,
o que, mesmo para redes de melhor esforo, pode ser minimizado se polticas de
gerenciamento de filas e tcnicas de controle de congestionamento apropriadas forem
utilizadas[6].
As redes de melhor esforo, representadas pelo protocolo IP, tm, como j
levantado inicialmente, a vantagem da simplicidade. Necessitam ento conviver com
servios mais completos e seguros, como o caso do protocolo TCP, por exemplo, usado
para suportar transferncia de dados mais confiveis, fim-a-fim, bidirecional e orientada
conexo, com mecanismos de controle de erros e seqenciamento de pacotes[7]. O TCP
visto como a fora motriz da Internet, com suporte operao de suas principais (e
pioneiras) aplicaes, como a web (HTTP), correio eletrnico e transferncia de arquivos
(FTP). Partindo da inadequao do modelo de servio de melhor esforo no fornecimento
de garantias de QoS para as aplicaes e da importncia do TCP na eficincia fim-a-fim
experimentada pelas aplicaes que o utilizam, conclui-se pela necessidade de mais
pesquisas voltadas s implicaes do desempenho do TCP no contexto das emergentes
arquiteturas para fornecimento de QoS em redes IP.
No entanto, nem todas as aplicaes requerem os servios confiveis providos
pelo TCP. Para esses sistemas o protocolo UDP foi desenvolvido com o intuito de oferecer
um servio de transporte orientado a datagramas, sem conexo e, portanto, no confivel,
sem garantias do dado ser disponibilizado na rede ou, ento, ser disponibilizado numa
ordem incorreta. Ao contrrio do TCP, o UDP no prov qualquer sistema de controle de
congesto e adaptao, disponibilizando assim uma forma mais rpida e direta de enviar e
receber dados, com um mnimo de sobrecarga, o que o torna propcio para aplicaes mais
sensveis ao tempo, como no caso das baseadas em voz e vdeo. Isto, aliado ao fato do
UDP no ser confivel, faz com que este protocolo necessite do suporte de mecanismos de
qualidade de servio. Significa dizer que, por questes de eficincia, no ideal o uso de

9

aplicaes mais crticas a atrasos ou perdas de pacotes, sob UDP em redes de melhor
esforo, onde no se tem garantia de QoS.
2.4 Classificao das Aplicaes
O entendimento do tipo de trfego gerado e o comportamento das aplicaes
so formas importantes para se determinar o modelo de QoS a ser disponibilizado aos
usurios. Em [12], o grupo de trabalho IntServ
2
, do IETF, classificou as aplicaes de
acordo com a diviso a seguir:
a) Aplicaes elsticas
b) Aplicaes de tempo real
b.1) Tolerantes
b.2) Intolerantes
Ento, com base nessa abordagem, e de uma forma sucinta, pode-se definir as
aplicaes da seguinte forma, classificadas de acordo com os seus requisitos de QoS:
2.4.1 Aplicaes Elsticas
So aquelas que sempre aguardam pela chegada dos dados, processando-os
imediatamente quando isto acontece, sem necessidade de buffer para uso posterior. Ou seja,
so aplicaes que podem tolerar altas variaes de vazo e perdas de pacotes, sem que
isso prejudique sua qualidade[13]. Como exemplo, tm-se as aplicaes de transferncias de
dados (FTP, e-mail), telnet e NFS, que so categorizadas de acordo com os requisitos de
atraso e vazo, como mostrado a seguir:
a) Asynchronous Bulk Traffic Quando os requisitos de atraso e vazo so
bastante flexveis, tal como e-mail e fax.
b) Interactive Burst Traffic So aplicaes com uma interao homem-
mquina, cujos requisitos so aproximados aos das aplicaes de tempo real

2
http://www.ietf.org/html.charters/intserv-charter.html.

10

e idealmente tm atrasos entre 200-300ms ou menos, mas que podem
tolerar algo ligeiramente acima disto[13]. Exemplos: telnet ou NFS.
c) Interactive Bulk Traffic So aplicaes interativas com exigncias de
atraso semelhantes s mostradas acima mas que, geralmente, seus usurios
esperam uma taxa de vazo maior. Exemplos: transferncia de dados (FTP)
e web (HTTP).
2.4.2 Aplicaes de Tempo Real
So as que no admitem atrasos, erros e variaes, tanto nos atrasos entre os
pacotes quanto na vazo, sendo sensveis ao tempo, como aplicaes de voz e vdeo, por
exemplo. Cobrem situaes em que os pacotes devem chegar no destino dentro de um
perodo de tempo limitado, sendo que, de outra forma, o pacote certamente ser
descartado. Usam armazenamentos no destino para suavizar a variao no tempo de
chegada do pacote, sendo, por isso, conhecidas como aplicaes playback, onde o
transmissor empacota e envia os dados e o receptor desempacota-os e tenta reproduzir o
mesmo sinal enviado. H, com isso, um nvel maior de fidelidade possvel, atravs da
disponibilizao de buffers, tal como descreve [12], que subdivide ainda as aplicaes de
tempo real em tolerantes e intolerantes.
a) Aplicaes de tempo real tolerantes so aquelas que aceitam certos nveis
de degradao dos requisitos de QoS (como perdas de pacotes), mantendo a
qualidade aceitvel e satisfatria atravs da operao dentro de uma escala
de proviso de QoS. So, por sua vez, subdivididas em adaptativas e no-
adaptativas.
a.1 Adaptativas so aquelas capazes de ajustar as demandas de
QoS dentro de um intervalo de valores aceitveis, sendo provocadas
por mecanismos que informam aplicao o atual nvel de eficincia
da rede[13]. Adaptao a perdas de pacotes, por exemplo, pode
indicar congestionamento na rede, tendo como conseqncia a
reduo das taxas de transmisso, tal como acontece no protocolo
TCP.

11

a.2 No-adaptativas so aquelas que no conseguem se ajustar da
mesma forma que as adaptativas, mas que podem tolerar alguma
variao nos requisitos de QoS. A qualidade de uma aplicao de
vdeo, por exemplo, pode ser degradada pela perda de uma certa
percentagem de pacotes, mas, mesmo assim, ainda poder ser
claramente visualizada (e entendida) pelos usurios.
b) Aplicaes de tempo real intolerantes so aplicaes que necessitam que
seus requisitos de QoS sejam rigorosamente obedecidos, pois, caso
contrrio, no realizaro suas tarefas suficientemente, resultando em
distores significativas na reproduo do sinal. Exemplos disso so as
aplicaes responsveis pelo controle remoto de equipamentos de misso
crtica, vistas em instrumentos de cirurgia e na robtica.
2.5 Modelos de QoS
Apresentam-se aqui os modelos (ou as arquiteturas) propostos no mbito do
IETF, comunidade internacional responsvel pela padronizao de tecnologias Internet,
para a implementao de QoS na rede mundial, fundamentada nos servios integrados e
diferenciados, sendo o ltimo o foco primordial desta dissertao.
2.5.1 Servio Integrado
Visando estender o servio de melhor esforo, na construo de uma infra-
estrutura mais robusta para a Internet que pudesse suportar o transporte de informaes em
tempo real, foi criado o grupo de trabalho de servios integrados do IETF. Tal fora tarefa
responsvel ainda em definir e padronizar interfaces e requisitos necessrios para a
implementao de um novo modelo de QoS. O grupo IntServ, como tambm ficou
conhecido, responsabilizou-se tambm em dar garantias de QoS ao longo de um percurso
de fluxo de dados, no qual todos os elementos de conectividade (roteadores) teriam que
suportar, atravs de mecanismos de sinalizao, a reserva de recursos. O RSVP exemplo
de protocolo de sinalizao e ser explicado ainda neste captulo. Os elementos de rede
devem, para tal reserva, estar em conformidade com um conjunto de recomendaes
(RFCs) relacionadas arquitetura IntServ, dentre as quais, destacam-se [15], [16] e [12],

12

sendo este ltimo o documento bsico que aborda os elementos da arquitetura, o modelo
em si, os mecanismos de controle de trfego e o protocolo RSVP.
O modelo de servio integrado ento marcado pela capacidade dos roteadores
em reservar recursos, de forma a prover qualidade de servio a fluxos de pacotes
especficos e individuais (e no a agregados de fluxos), com informaes sobre tais
recursos
3
mantidas em cada roteador ao longo dos percursos tomados pelos fluxos
4
. E, por
operar com fluxos individuais que o modelo IntServ tem como caracterstica mais
particular a alta granularidade na reserva de recursos, com um controle fino das
solicitaes, que so iniciadas pelas aplicaes que requeiram garantias de QoS. Isto tido
como vantagem do modelo, pois h uma maior preciso no uso e na alocao dos recursos.
Entretanto, para que tal granularidade seja possvel, necessrio que cada elemento da rede
(roteadores e, inclusive, as estaes que hospedam as aplicaes) ao longo do percurso
mantido pelo fluxo participe do processo de sinalizao e alocao. Desta forma, a
arquitetura torna-se pesada, pouco escalar e, conseqentemente, imprpria para redes
abrangentes, como a Internet.
O grupo IntServ desenvolveu suporte para duas amplas classes de
aplicaes[14], quais sejam:
a) Aplicaes de tempo real, com restries nos requisitos de QoS, como j
apresentado recentemente;
b) Aplicaes tradicionais, onde os usurios buscam nveis de eficincia
similares aos providos pelas redes de melhor esforo.
A primeira classe de aplicaes deu base para o grupo de trabalho padronizar o
servio garantido[15] (guaranteed service) e, a segunda classe, para o servio de carga
controlada[16] (controlled load service), com, ambas, representando a implementao dos
servios integrados.

3
Tambm conhecidas como informaes de estado.
4
Qualquer conjunto de pacotes identificvel, que parte de uma origem para um ou mais receptores, com um
tratamento comum de qualidade de servio[14]. De uma outra forma, tem-se um fluxo de dados quando um
conjunto de pacotes transportado de um ponto de origem a outro de destino, usando, para cada extremo,
pelo menos, o mesmo endereo IP, a mesma porta de conexo e o mesmo protocolo de transporte.

13

2.5.1.1 Servio Garantido (Guaranteed Service)
Servio garantido a implementao IntServ onde as mtricas de QoS so
asseguradas. Ou seja, onde os nveis de vazo so garantidos, a proteo contra perdas de
pacotes mantida e os limites rgidos de atraso so propiciados. No entanto, a variao no
atraso entre os pacotes (jitter), no garantida[15].
O servio prprio para aplicaes com requisitos rgidos de tempo real, que,
para o alcance de resultados satisfatrios, necessitam que as mtricas acima descritas sejam
alcanadas. Basicamente, com este tipo de servio, a taxa de transmisso dos pacotes
cumprida, sendo exigido que todos os ns intermedirios o implemente, o que torna o
servio muito pouco escalvel.
2.5.1.2 Servio de Carga Controlada (Controlled Load Service)
De outra maneira, a implementao IntServ do tipo carga controlada ,
fundamentalmente, aquela que, sob condies controladas (sem congestionamentos), se
aproxima do comportamento de aplicaes que recebam o servio de melhor esforo.
Assume-se, a partir de [16], que pequenas taxas de descarte de pacotes so permitidas e que
a maioria dos pacotes devero apresentar valores de atrasos prximos ao atraso mnimo dos
pacotes bem sucedidos (no descartados). A grande diferena entre os servios de carga
controlada e de melhor esforo que, no primeiro, os fluxos no sofrem grandes
deterioraes com o aumento da carga na rede.
Como j sinalizado recentemente, as aplicaes aqui definidas como
tradicionais, em que nveis prximos aos oferecidos em redes de melhor esforo so
providos, formam a base para a padronizao do servio de carga controlada. No entanto,
como este servio garante um certo atraso mdio, com o atraso experimentado por alguns
pacotes no podendo ser determinado, pode-se indic-lo s aplicaes do tipo tempo real
tolerantes[18] [19], que funcionam bem quando a rede no est sobrecarregada.
2.5.1.3 Componentes para implementao do IntServ
O modelo de referncia para implementao da arquitetura IntServ inclui as
funes necessrias para o fornecimento dos servios, sendo composto por quatro
componentes, conforme descrio a seguir:

14

a) Classificador permite identificar a quais fluxos os pacotes pertencem e a quais
classes de QoS os mesmos sero atribudos. Cada pacote recebido no roteador
deve ser mapeado em alguma classe, com todos os pacotes da mesma classe
recebendo o mesmo tratamento no escalonador. O conceito de classe , na
verdade, uma abstrao, j que o mesmo pacote pode ser classificado de
diferentes formas pelos roteadores que compem o percurso do pacote,
dependendo da concepo adotada. Por exemplo, roteadores de borda podem
utilizar uma classe para cada fluxo e os roteadores internos podem mapear vrios
fluxos numa nica classe.
b) Escalonador de pacotes gerencia, atravs de polticas de enfileiramento, o
encaminhamento dos fluxos na rede, de modo a satisfazer os requisitos de QoS.
Um componente que pode ser considerado como parte do escalonador o
avaliador, responsvel por medir as caractersticas de trfego dos fluxos, de
forma a auxiliar no escalonamento e no controle de admisso.
c) Controle de admisso determina a existncia de recursos, decidindo se um
pedido de alocao pode ser garantido ou no. Compreende algoritmos de
deciso, implementados pelos roteadores, para determinar se um fluxo pode ter
sua qualidade de servio garantida, sem que outros fluxos, j com seus recursos
alocados, sejam afetados.
d) Protocolo de reserva antes de encaminhar seus dados pela rede, as aplicaes
devem, atravs de um processo de sinalizao, negociar a reserva de recursos
necessrios para tal transmisso. Para isto utilizam, geralmente, um protocolo de
sinalizao, que, na maioria das vezes, o RSVP, desenvolvido para atuar em
redes com servio integrado. O RSVP utilizado tanto pelos sistemas finais como
pelos roteadores da rede. No primeiro caso, o protocolo solicita nveis especficos
de QoS para as aplicaes. J referente ao uso pelos roteadores, o RSVP
responsvel em repassar as requisies aos demais roteadores do percurso por
onde os dados sero transmitidos, assim como estabelecer e manter as
informaes de estado suficientes para o servio. Um fato importante que todos
os roteadores que compem o caminho dos dados das aplicaes devem participar
do processo de reserva de recursos, sobrecarregando a rede e contribuindo para a

15

baixa escalabilidade da soluo. Dentre as caractersticas do RSVP, podem ser
destacadas as seguintes:
- O estilo de reserva de recurso adotado pelo RSVP o soft-state, tambm
conhecido como sem conexo (connectionless). Ou seja, as informaes
de estado tm um perodo de validade, so mantidas em cache e,
periodicamente, so refrescadas pelos sistemas finais. As informaes no
utilizadas por um certo tempo so expiradas e as alteradas por um
roteador so, automaticamente, difundidas pela rota;
- O RSVP utiliza o conceito de receiver-initiation. Isto , quem
responsvel por iniciar e manter as reservas o n receptor, que sabe o
que quer (ou pode) receber;
- RSVP um protocolo de sinalizao e, no, de roteamento. Da mesma
forma, no um protocolo de transporte e, portanto, no carrega dados.
Para isto, trabalha em paralelo com os protocolos TCP ou UDP;
- Roteadores que compem o percurso dos dados, mas que no
implementam o protocolo RSVP, no inviabilizam o processo de qualidade
de servio, j que encaminham transparentemente as mensagens. No
entanto, isto cria pontos-fracos na rede, onde o servio retoma a
concepo de melhor esforo, sem alocao de recursos nesses ns.
- O protocolo IP, nas verses 4 e 6, suporta o RSVP.
2.5.1.4 Crticas ao modelo IntServ
Na arquitetura de servio integrado, a qualidade de servio obtida atravs da
reserva de recursos por fluxo, o que, como j descrito, torna o modelo bastante granular,
com uma grande preciso (controle fino) no uso e na alocao dos recursos. Esta a
vantagem do projeto, assim como o fato do IntServ ter sido projetado como extenso do
servio utilizado na Internet (melhor esforo) e, tambm, por no ter havido necessidade de
modificaes dos mecanismos de roteamento dos pacotes. No entanto, para que as
garantias de QoS sejam efetivas, necessrio que todos os roteadores ao longo do percurso
do trfego implementem a classificao e o escalonamento de pacotes, o controle de

16

admisso e, principalmente, a sinalizao de recursos. Isto tudo gera um grande problema
de escalabilidade e torna o modelo impraticvel para grandes redes, como a Internet, pois
impe, em termos de processamento e armazenamento, sobrecarga aos roteadores. Em
outras palavras, quanto maior a extenso da rede, maior a quantidade de fluxos que os
roteadores tero que tratar e, da mesma forma, maior ser a quantidade de informaes de
estado que esses elementos tero que manter
5
, impondo esforo excessivo sobre toda a
rede. Foi justamente o problema de escalabilidade que possibilitou o estudo de solues
alternativas para a qualidade de servio na Internet, sendo proposto pelo IETF o modelo de
servio diferenciado, com o qual os estudos experimentais deste trabalho so
implementados.
2.5.2 Servio Diferenciado
O modelo de diferenciao de servio foi projetado como um mecanismo
escalvel para funcionar no centro de redes globais, como a Internet. O servio diferenciado
no guarda informaes de estado sobre fluxos individuais e, por isso, no granular como
o IntServ. Ao contrrio, o DiffServ baseado na agregao de fluxos, com reservas sendo
feitas para um conjunto de fluxos relacionados (conhecidos como BA Behavior
Aggregate), sem cargas de sinalizao e, portanto, com menos sobrecarga. esta a base da
escalabilidade do modelo. Por no ser granular, o DiffServ no pode garantir os recursos
para todos os fluxos que compem o agregado. muito importante saber que as reservas
so alocadas para o BA e, desta maneira, um fluxo individual pode no atingir seus
requisitos em termos de qualidade de servio[3] (atraso, vazo, taxa de perdas). Entretanto,
desde que a rede esteja corretamente provisionada, se pode alcanar, sim, nveis
satisfatrios de garantia de recursos em redes com implementao dos servios
diferenciados.
O modelo baseia-se em agregar fluxos de dados com os mesmos requisitos,
sendo que a informao de estado desse agregado transportada no prprio cabealho IP e
usada pelos roteadores como uma forma simples e eficiente de classificar os pacotes, com
vistas a promover, entre eles, tratamentos diferenciados.

5
Se a sinalizao for realizada pelo RSVP, este, como j descrito, trabalha com o estado leve. Isto quer
dizer que as informaes devero ser atualizadas periodicamente, o que prejudica ainda mais a
escalabilidade.

17

Na verdade, a idia de diferenciar trfego, ao nvel do protocolo IP, no
recente. Antes do aparecimento do DiffServ, bits j indicavam uma prioridade relativa ou o
tipo de servio desejado, de forma a influenciar no percurso que os pacotes poderiam
seguir. Trata-se do campo ToS (Type of Service)
6
do cabealho IPv4, mostrado na Figura
2-1 e definido pelas RFCs 791[21] e 1349[22] para especificar como o pacote seria
manipulado pelos roteadores. Os trs primeiros bits so os nveis de precedncia (ou
prioridade relativa) e servem para os transmissores identificar a importncia de cada pacote.
Os 4 bits seguintes funcionam como chaves de classificao, servindo para especificar o tipo
de transporte desejado. O bit 3 (D), quando ligado, significa que est sendo requisitado um
baixo delay ao pacote; o bit 4 (T), por sua vez, sinaliza necessidade de alta vazo; o bit 5
(R) indica alta credibilidade na entrega do pacote e, por fim, o bit 6 (M), que especifica
mnimo custo. Caso os quatro bits estejam desligados, isso vai significar que no h servio
especial a ser tratado. Ocorre que, na prtica, a RFC 1349 no foi satisfatoriamente
implementada pelos fabricantes de roteadores, por ser considerado um modelo limitado
quanto diferenciao de trfego, uma vez que o sub-campo Precedncia permite apenas
prioridade relativa aos pacotes
7
. O IETF reviu o modelo que disponibilizava QoS por meio
do uso de classes de trfegos e de chaves de classificao e ento remodelou o byte IPv4
TOS para o campo DiffServ (DS), o qual permite uma variedade maior dos tipos de pacotes
que podero ser enfileirados e escalonados na rede.

Figura 2-1 O original byte TOS do IPv4.
A Figura 2-2 mostra a nova configurao, onde se pode observar que os seis
bits do antigo byte TOS formam agora o DSCP (DiffServ Code Point), com a possibilidade
de permitir, teoricamente, 2
6
(64) cdigos distintos para representar comportamentos de
enfileiramento e escalonamento dos pacotes. Os bits 6 e 7 no so utilizados.

6
Com 1 byte (8 bits) de comprimento.
7
Exemplo: pacotes com precedncia 7 vm antes dos com identificao 6 e assim por diante.

18

O fato que o modelo DiffServ consegue diferenciar trfego ao nvel das filas,
dos escalonadores, das rotas ou de outros fatores que possam interferir no desempenho dos
servios, o que o torna mais flexvel do que um mecanismo de simples prioridade. Alm
disso, pode-se disponibilizar mais servios com o DSCP do que a classificao por tipo de
servio (campo ToS). Vale lembrar ainda que, pelas normas, o campo DS, ao contrrio do
TOS, no mais sugere seleo de rotas[14]. Para informao, no IPv6, o campo redefinido
pela RFC 2474 o TC (Traffic Class), que, em relao ao IPv4, utilizado exatamente
para o mesmo fim.

Figura 2-2 Campo DS do cabealho IPv4, definido pela RFC 2474.
Apesar de suas vantagens, o modelo DiffServ oferece tambm alguns
problemas, como, por exemplo, no garantir recursos para todos os fluxos, com as reservas
sendo feitas para a agregao como um todo (BA). Ao contrrio do modelo IntServ, com o
DiffServ no h o chamado controle fino das solicitaes. Ou seja, a arquitetura apresenta
baixa granularidade na reserva de recursos, com pouca preciso no uso e na alocao desses
recursos.
2.5.3 Redes IntServ sobre DiffServ
Como se percebe, ambos os modelos apresentam vantagens e desvantagens.
Com o intuito de aproveitar os benefcios das arquiteturas e aplic-las em redes
geograficamente extensas, como a Internet, estudos tm sido realizados para sugerir uma
soluo hbrida, atravs da combinao dos modelos de qualidade de servio propostos pelo
IETF. Na verdade, conhece-se a soluo como redes IntServ sobre DiffServ, onde, para
prover maior granularidade nas solicitaes, os mecanismos de reserva e sinalizao do
servio integrado so utilizados nas redes perifricas ou de acesso e, para maior alcance e
escalabilidade, se emprega o modelo diferenciado na rede central, tambm conhecida como
redes de trnsito, tal como mostra a Figura 2-3.
A complexidade da soluo reside, principalmente, nos roteadores, que so os
responsveis pelo mapeamento entre as capacidades dos modelos, expressando aspectos

19

como: a transformao das classes do IntServ em comportamentos do servio DiffServ
(PHB, a ser visto no Captulo 3); policiamentos adequados na regio central e, ainda na
rede diferenciada, o gerenciamento de recursos, traduzido pelo controle de admisso,
efetuado a partir da disponibilidade de recursos no domnio DiffServ. Nesta linha de
pesquisa, [24], por exemplo, apresenta uma plataforma de testes em Linux, que explora o
mapeamento de fluxos sinalizados na rede IntServ em classes no interior do domnio
DiffServ. [25], por sua vez, implementa, tambm atravs de um testbed, o provisionamento
dinmico de recursos num domnio diferenciado, por meio de negociadores de banda
8
e do
protocolo COPS[26][27], que, trabalhando cooperativamente, so responsveis pela troca
dinmica de informaes sobre polticas de QoS.
Figura 2-3 Modelo que combina as arquiteturas integrada e diferenciada.
Uma descrio complementar dos servios diferenciados pode ser encontrada
mais adiante, no Captulo 3.
2.6 Mtricas da qualidade de servio
As sesses seguintes definem as mtricas essenciais para o estudo da qualidade
de servio provida pelas redes s aplicaes. Esto inclusos neste contexto o atraso sofrido
pelos pacotes e a variao do atraso entre esses mesmos pacotes, assim como a taxa de
descarte, a vazo de dados e a largura de banda.

8
Conhecidos como Bandwidth Broker ou, simplesmente, BB.
RBS
RBE
RI RBS RBE

20

2.6.1 Atraso
De uma forma genrica, atraso (ou retardo) o intervalo de tempo que os
pacotes levam para percorrer seu caminho, do transmissor ao receptor, incluindo,
obviamente, os retardos gerados pela prpria rede, como os provocados pelas decises de
roteamento e pela permanncia dos pacotes nas filas dos roteadores da rede.
O tipo de atraso considerado nos experimentos deste trabalho o conhecido
como atraso em um sentido (one-way delay ou OWD). Os conceitos de wire time e host
time, abordados pelo grupo de trabalho IPPM, do IETF, so fundamentais para o
entendimento do OWD. A noo de wire time assume que o dispositivo de medio tem
um posto de observao na ligao IP, onde se considera que o pacote tenha entrado no
canal quando o primeiro bit aparecer no ponto de observao do transmissor e o pacote sai
do canal quando o ltimo bit do pacote passar pelo ponto de observao do receptor. O
OWD, formalmente definido em [28], medido justamente dentro deste conceito, a partir
do tempo que o pacote tenha entrado no posto de observao do transmissor at o tempo
que o ltimo bit tenha sido observado pelo receptor, sendo a diferena desses dois valores o
atraso em um sentido. A Figura 2-4 ajuda a compreender isto. A noo de host time, por
sua vez, tida quando a medio realizada por meio de software, atravs do registro dos
tempos (timestamps) de transmisso e recepo dos pacotes. Esta a noo adotada por
uma das ferramentas de gerao de pacotes utilizada nos estudos experimentais deste
trabalho, como ser visto na Sesso 4.2.3.

Figura 2-4 Conceito de atraso em um sentido (OWD).
2.6.2 Variao do atraso entre pacotes (jitter)
O jitter, tambm conhecido como Instantaneous Packet Delay Variation ou
IPDV-jitter, formalmente definido em [29] e refere-se variao do atraso entre pacotes

21

selecionados. De uma outra forma, o jitter baseia-se nas medidas do delay de um sentido e
se define a partir de pares consecutivos de pacotes. Logo, o requisito para se medir o jitter
a existncia de, pelo menos, dois pacotes.
Considerando-se D
i
como o OWD do i-simo pacote, ento o jitter relacionado
quele pacote medido como o mdulo de (D
i
- D
i-1
). Ou seja, jitter a diferena modular
entre os valores de atrasos de um sentido de pacotes selecionados, sendo calculado como
|(D
i
- D
i-1
)|.
Um importante uso do jitter est no estudo do dimensionamento de buffers para
aplicaes, como as de voz e de vdeo, que requerem uma entrega regular de pacotes. Ou
seja, do lado do transmissor os pacotes so enviados continuamente, com um certo
espaamento entre eles. Devido aos congestionamentos da rede ou aos problemas de
enfileiramento, este fluxo pode se tornar irregular, com atrasos variados entre cada pacote,
conforme se pode visualizar na Figura 2-5. Quando um roteador recebe um fluxo de voz
sobre IP, por exemplo, ele deve compensar a variao encontrada, armazenando esses
pacotes em buffer (ou playout buffer delay) e, depois, jogando-os, num fluxo estvel,
para o processador de sinais digitais (Digital Signal Processor ou DSP), onde ser
convertido para um fluxo analgico (Figura 2-6). Caso o jitter seja grande o suficiente para
fazer com que pacotes sejam recebidos fora do limite do buffer, pacotes sero descartados e
falhas sero escutadas no udio. No entanto, pequenas taxas de perda podem ser, atravs de
tcnicas de interpolao de pacotes, recuperadas pelo DSP, sem prejuzo da escuta.

Figura 2-5 Ocorrncia de variaes de delays entre pacotes.

22

Figura 2-6 Atuao do buffer na estabilizao dos fluxos com jitter.
Como visto na sesso anterior, a perda de pacotes pode causar problemas srios
s aplicaes de tempo real, como voz sobre IP, por exemplo, comprometendo a qualidade
dessas aplicaes. Por causa disto, tcnicas de recuperao por redundncia, como o FEC
(Forward Error Correction), tentam minimizar a taxa de perda de quadros de voz,
associada a uma certa taxa de perda de pacotes[30]. Protocolos como TCP se recuperam
bem desses problemas, uma vez que efetuam retransmisso de pacotes em caso de perda. O
protocolo UDP, mais comumente utilizado em transmisses de voz e vdeo, por sua vez,
no recupera perdas e, desta forma, tende apresentar maior quantidade de pacotes perdidos.
O parmetro estudado neste trabalho que se relaciona com as perdas a taxa
de perda de pacotes, calculado, no lado do receptor, como a razo entre a quantidade de
pacotes perdidos e a quantidade de pacotes transmitidos, dentro do perodo de anlise
9
.
2.6.3 Largura de banda e Vazo
Largura de banda de um link representa a capacidade mxima de transmisso de
uma conexo, sendo comumente expressada em kilobits por segundo (Kbps) ou megabits
por segundo (Mbps).

9
Percentagem calculada atravs da frmula: Taxa de perda = (N
o
de pacotes perdidos/ N
o
de pacotes
transmitidos)*100.

23

A largura de banda pode ser entendida a partir da analogia com os canos
dgua, com um certo dimetro de espessura. Quanto maior for este dimetro, maior ser a
quantidade de gua por segundo que poder passar atravs do cano. Aqui, no caso, o
dimetro a largura de banda, o cano representa a ligao de rede e, a gua, significa os
dados.
Vazo , justamente, a quantidade de dados que a rede capaz de transmitir de
um lado a outro, num certo perodo de tempo. Voltando analogia, vazo seria a
quantidade de gua por segundo que passa atravs do cano. A vazo tambm expressa em
Kbps ou Mbps.
Este captulo mostrou aspectos bsicos, mas imprescindveis, sobre QoS. Foram
apresentadas justificativas e questes restritivas para a implantao da qualidade de servio
nas redes de computadores. Destacou-se a importncia do tema, que alvo de estudos e
pesquisas crescentes, responsveis pelo estabelecimento de padres internacionais e pela
disponibilizao de produtos de mercado.
Mostrou-se ainda a necessidade da classificao das aplicaes para a
determinao dos modelos de QoS (IntServ e DiffServ), os quais foram abordados dentro
de uma viso crtica, com a apresentao de suas vantagens e desvantagens.
O captulo foi finalizado com a definio das mtricas essenciais para a pesquisa
de QoS: atraso dos pacotes, a variao desses atrasos, o descarte de pacotes, a vazo de
dados e a largura de banda.

24

3. Servios Diferenciados (DiffServ)
Complementam-se aqui as definies apresentadas no captulo anterior,
abordando, dentre outras coisas, questes como o condicionamento de trfego no modelo
diferenciado (suas funes e seus mecanismos), o conceito de comportamento por n, a
implementao DiffServ no Linux e as aplicaes de voz sobre IP.
3.1 Condicionamento de Trfego no modelo DiffServ
O trfego que ingressa numa rede com servio diferenciado deve ser submetido
a uma srie de elementos funcionais, os quais so mantidos pela arquitetura e responsveis
pelo condicionamento daquele trfego. Ou seja, os fluxos so classificados, condicionados,
marcados e, ento, associados a diferentes tipos de agregados (BA), atravs da gravao do
valor DSCP correspondente. Percebe-se ento que o modelo diferenciado adota um
conjunto de funes, que so implementadas nos ns da rede. Incluem-se a, alm dos
classificadores, medidores, marcadores, suavizadores e policiadores (ou descartadores),
como se pode visualizar na Figura 3-1:

Figura 3-1 Elementos de condicionamento de trfego
O classificador o primeiro elemento de condicionamento de trfego e
responsvel pela seleo dos pacotes, baseada no contedo de parte(s) do cabealho. Se tal
seleo ocorrer na entrada de uma rede DS (ou seja, o pacote originrio de uma rede sem
servio diferenciado), a classificao pode ser avaliada em vrios campos do pacote
(endereo IP de destino, ToS e protocolo de transporte, por exemplo). Chama-se esse tipo
de classificao de multicampo (Mult-Field ou MF). Caso a classificao seja baseada
apenas no campo DSCP, ou seja, o pacote j veio marcado de um domnio DS, com o

25

campo DSCP correspondente a um determinado tipo de trfego, a classificao conhecida
ento como de comportamento agregado (Behavior Aggregate ou BA, como j citado
anteriormente).
O medidor responsvel por verificar a conformidade do trfego em relao ao
perfil contratado, com base na medio de propriedades temporais dos fluxos de pacotes.
Balde de fichas uma das implementaes de medidores conhecidas. A partir do resultado
da medio, ser tomada sobre o pacote uma ao de condicionamento, que pode ser
marcao (ou remarcao), suavizao ou descarte.
O marcador rotula o pacote, redirecionando-o para um determinado fluxo.
responsvel tambm em realizar a remarcao dos pacotes (aumentando ou diminuindo sua
prioridade). Atrasar os pacotes at que estes estejam em conformidade com o perfil
contratado e possam ser liberados para transitarem na rede a funo do suavizador. Os
pacotes que foram considerados pelo medidor como em no conformidade com o perfil
contratado, podem ser descartados pelo policiador, que pode ser implementado como um
caso especial de suavizador, sem buffer de espera[31].
3.1.1 Funes de condicionamento de trfego
As funes de condicionamento de trfego so realizadas pelo modelo DiffServ
dentro do chamado domnio de servios diferenciados (ou simplesmente domnio DS,
exemplificado na Figura 3-2), que composto por um conjunto de ns compatveis com a
arquitetura diferenciada. O domnio DS, geralmente, apresenta ns de entrada
(INGRESSO), de sada (EGRESSO) e internos, sendo que os de entrada e sada so dados
como ns de fronteira, j que atuam como pontos de demarcao entre domnios
diferenciados ou entre estes e domnios no compatveis com o modelo. Tipicamente, os
ns de borda
10
realizam condicionamento de trfego, classificando os pacotes que chegam,
num agregado pr-definido; medindo-os para determinar a conformidade dos perfis de
trfego; marcando o campo DSCP apropriadamente, atrasando o trfego quando necessrio
e at descartando os pacotes, em caso de congestionamentos. Realizam, na verdade, as
funes mais complexas das executadas num domnio DS, uma vez que os ns interiores
somente aplicam o comportamento (PHB) apropriado, empregando tcnicas de

10
Como tambm so conhecidos os ns de fronteira, representados, na Figura 3-2, pelos ns 1, 4 e 5.

26

policiamento ou suavizao, e, algumas vezes, praticam remarcao de pacotes,
dependendo da poltica do domnio. So as diferentes funcionalidades exercidas pelos
roteadores, num domnio DS.

Figura 3-2 Domnio de Servios Diferenciados

3.1.2 Mecanismos de medio e policiamento de trfego
A marcao e o policiamento de pacotes compartilham a funo de medio,
para determinar se cada pacote est ou no em conformidade com o perfil contratado (in
profile e out profile, respectivamente). Um simples exemplo o clssico mtodo de balde
de fichas (token bucket), que fora um padro de sada constante, mesmo em casos de
rajadas de trfego. O balde retm uma quantidade limitada de fichas (tokens), a que se
chama tamanho do balde (bucket size), e essas fichas so geradas em ciclos de relgio do
sistema operacional (clocks), a cada intervalo constante de tempo (t segundos), numa
certa taxa de renovao, e removidas do balde medida que os pacotes de rede chegam.
Na verdade, cada ficha representa a permisso de enviar um certo nmero de bits na rede,
sendo que, para transmitir um pacote, um nmero de fichas correspondendo ao tamanho
daquele pacote deve ser removido do balde. Ou seja, para cada pacote que chega
verificado se h fichas disponveis para ele. Havendo, elas so removidas e o pacote
considerado dentro do perfil. Por outro lado, se no houver qualquer ficha disponvel no
balde quando o pacote chegar, considera-se que o mesmo est fora do perfil, podendo ser
reclassificado ou at mesmo descartado pelo mecanismo. Neste caso, quando h descarte de

27

pacotes, o token bucket funciona como um policiador de trfego. A Figura 3-3 ilustra o
mecanismo, que, para facilitar o entendimento, relaciona apenas uma ficha para cada pacote.
Como o tamanho do balde finito e fixado pelo usurio, pequenas rajadas de
rede podem ser toleradas, com pacotes pertencentes a essas rajadas sendo ainda
considerados dentro do perfil. Na verdade, a seleo dos parmetros tamanho do balde e
taxa de renovao de fichas que vai tanto determinar o perfil, forando uma taxa mdia
de encaminhamento de pacotes, quanto controlar o tamanho das rajadas permitidas.
Figura 3-3 Mtodo do Balde de Fichas
Outra forma utilizada para medio e policiamento de trfego o de balde
furado (leaky bucket), que consiste em encaminhar os pacotes para escalonamento numa
mesma freqncia (taxa fixa de transmisso), no importando o intervalo de chegada entre
eles e nem se chegam em rajadas. Ou seja, estabiliza a transmisso de fluxos de pacotes
irregulares, diminuindo as chances de congestionamento nos ns posteriores.
O mtodo acima funciona como um suavizador de trfego, limitando a
freqncia com que uma fila ser servida, mesmo quando o escalonador esteja ocioso.
O balde furado apresenta um buffer (o bucket) para depositar os pacotes que
chegam. Como esse tem comprimento limitado e, portanto, em momentos de rajadas
maiores pode receber mais pacotes do que sua capacidade, transbordando o balde, o
Balde de Fichas Balde de Fichas Balde de Fichas
Pacotes
que chegam...
... tomam as
fichas
disponveis
tamanho
do balde
pacote dentro do perfil pacote fora
do perfil

28

mecanismo age tambm como policiador de trfego, pois pacotes que chegarem com o
buffer cheio certamente sero descartados.
3.2 Acordo de nvel de servio (SLA)
Acordo de nvel de servio, no contexto deste trabalho, definido como um
contrato entre provedores de servios (provedor Internet ou ISP, por exemplo) ou entre um
provedor de servio e seus clientes. SLA especifica, geralmente em termos mensurveis, o
nvel de qualidade de servio que pode ser esperado ou, de outra forma, pode ser visto
como um contrato que determina quais servios o provedor de servio ir fornecer e quais
penalidades o mesmo ir sofrer, caso no cumpra com os compromissos firmados.
Na especificao dos servios podem constar parmetros relacionados a nveis
de disponibilidade, de desempenho, de operao ou outros atributos do servio, como
suporte ao usurio e credibilidade.
Em termos de mtricas de desempenho, so geralmente caracterizados
parmetros como os de tempo de resposta, vazo, atrasos, perdas e utilizao dos sistemas.
Mtricas de vazo, por exemplo, definem as taxas com que os dados so liberados ao
cliente, tal como: no horrio de trabalho, usurios da Intranet devero carregar arquivos de
imagem (.gif), de at 65Kbytes, em, no mximo, 10 segundos. J a mtrica de tempo de
resposta define o tempo mximo de resposta de uma aplicao, frente s requisies de um
usurio, expressando acordos como: 90% dos usurios devero experimentar um tempo de
resposta de, no mximo, 2 segundos durante os horrios de pico (10 s 12h e 16 s 18h).
Para facilitar especificaes de QoS dentro de um contrato, um SLA deve
conter, visando descrever o servio, um conjunto de parmetros mais tcnicos, conhecidos
como especificaes de nvel de servio (SLS ou Service Level Specifications). Tais
parmetros caracterizam, por exemplo, na viso do servio diferenciado, perfis de trfegos
agregados e as formas de encaminhamento de cada agregado de fluxos. O SLS pode
especificar ainda, segundo [36], outros requisitos, como:
! mecanismos de autenticao e criptografia utilizados;
! aes (comandos) a serem executadas em caso de descontinuidade dos
servios;

29

! monitorao e auditoria do QoS provido e;
! restries no roteamento de trfego agregado.
Num ambiente de rede em que vrios limites so atingidos (situao com
interdomnios diferenciados, por exemplo), os SLAs podem ser gerenciados de duas
maneiras distintas: esttico ou dinamicamente. Se o nmero de servios oferecidos
pequeno, os SLSs entre os domnios podem ser manualmente negociados e os roteadores de
borda configurados por administradores de rede. Isto significa que o contrato SLA feito
estaticamente, entre partes humanas, e que seus termos no podem ser alterados sem uma
interveno do administrador (ver Figura 3-4). Entretanto, em redes muito extensas, como a
Internet, mais vivel, entre os domnios, a implementao de mecanismos dinmicos para
manipular a sinalizao de QoS e a proviso de recursos. Ou seja, so entidades que
automatizam o processo de negociao de SLS e controle de admisso, de modo a
configurar corretamente os dispositivos de rede e suportar os servios de QoS acordados.
Essa entidade o negociador de largura de banda (BB ou Bandwidth Broker), responsvel
em garantir que os recursos dentro dos domnios diferenciados e em ligaes conectando
domnios adjacentes sejam corretamente alocados (ver Figura 3-5).
Um BB mantm informaes relativas aos SLSs definidos entre o domnio
diferenciado e seus clientes
11
, e utiliza estas informaes para gerenciar os recursos de rede,
configurar os roteadores do domnio local e tomar decises relativas ao controle de
admisso.
Para verificar se uma solicitao de recursos de um usurio pode ser atendida
atravs dos domnios, preciso que o BB do domnio do usurio se comunique com os BBs
dos demais domnios. Esta comunicao geralmente implementada atravs de sinalizao,
utilizando protocolos para este fim, como o RSVP.
A implementao de gerenciamento dinmico de SLA em redes extensas ,
como se pode imaginar, bastante complexa. Para enfrentar este desafio, a iniciativa
Internet2 QBONE[37] tem agrupado redes de pesquisa, grupos de universidades,
engenheiros, pesquisadores, desenvolvedores de aplicao e redes de agncias federais para

11
O termo clientes inclui os usurios locais do domnio em que o BB se encontra, bem como as redes
adjacentes.

30

construir um testbed em interdomnios com servios diferenciados. Este foi, apesar de
grandes dificuldades ainda encontradas para implementar o projeto
12
, o primeiro esforo
dessa natureza em testar o servio diferenciado em redes geograficamente remotas e a
primeira experincia com protocolos de sinalizao em interdomnios DiffServ.

Figura 3-4 SLA esttico

Figura 3-5 SLA dinmico, com uso de BBs
3.3 Per-Hop Behavior (PHB)
Um dos conceitos mais importantes em servios diferenciados o de
comportamentos por n (Per-Hop Behavior PHB), definido como um tratamento,
observado externamente, que dado aos pacotes de um certo agregado[32] de fluxos,
marcados com o mesmo cdigo DS (DSCP) e com o mesmo tratamento no
encaminhamento dos pacotes. O PHB define o tratamento a ser oferecido ao pacote, at
quando este for encaminhado ou descartado em cada n, sendo selecionado por meio de um
mapeamento entre o DSCP (que identifica a agregao) e o tratamento que os agregados
devem receber no domnio DS. Os fluxos pertencentes a uma agregao sero servidos,

12
Um dos servios originalmente projetados foi o Internet2 Qbone Premium Service, que se encontra
atualmente inativo, em funo de barreiras, como: complexidade no policiamento dos roteadores em cada

31

num domnio DS, de acordo com a combinao de todos os PHBs concedidos a eles ao
longo do caminho percorrido no interior do domnio[33]. Ou seja, o resultado de uma
transmisso (o servio fim a fim) conseguido atravs da combinao dos PHBs entre os
domnios, ao longo do percurso[17]. De uma outra forma ainda, os comportamentos
(PHBs) individuais aplicados em cada roteador, por si s, no garantem uma qualidade de
servio fim-a-fim, mas conseguem faz-lo se forem aplicados aos roteadores do domnio
DS.
Alm do PHB default, que serve para representar o trfego de melhor esforo e
garantir a compatibilidade em todos os roteadores, dois PHBs so padronizados pelo IETF:
o de encaminhamento assegurado (PHB AF Assured Forwarding)[35] e o de
encaminhamento expresso (PHB EF Expedited Forwarding)[34]. O primeiro, tambm
conhecido como servio premium ou de canal dedicado virtual, pode ser usado para trfego
com requisitos de baixa perda, baixo atraso, baixo jitter (variao dos atrasos) e garantia de
largura de banda, alcanados desde que, aos fluxos agregados sejam assegurados pouco ou
nenhum enfileiramento. Para isso, ou seja, para garantir pouca ocupao nas filas com
trfego EF, requerido que a taxa de servio dada ao agregado de pacotes EF, na sada do
roteador, exceda sua taxa de entrada sobre longos e curtos intervalos de tempos,
independentemente da carga de outros tipos de trfego[34]. O PHB EF propcio para
trfego de tempo real (como VoIP) e, por isso, foi aplicado nos testes aqui explanados. O
PHB AF, por sua vez, baseia-se numa expectativa de servio, concebida em momentos de
congestionamento, sem garantias de que os requisitos (perdas de pacotes, por exemplo)
sejam atingidos. Com este comportamento podem ser providas 04 classes independentes,
cada uma com 03 nveis de descarte, o que conduz ao total de 12 diferentes cdigos AF
(DSCPs).
3.3.1 Encaminhamento Assegurado (PHB AF)
O comportamento AF prov classes distintas de trfegos, com variao de
nveis de probabilidades de perda. Desta forma, como ligeiramente sinalizado acima, dois
distintos contextos de classificao so codificados dentro do DSCP: a classe de servio do
pacote e seu respectivo nvel de precedncia para descarte. Ou seja, so disponibilizadas 4

domnio, carncia na disponibilidade de aplicaes e custos operacionais.

32

classes diferentes, tendo, cada uma, 3 nveis de precedncia, correspondendo, dentro de
cada classe, a uma maior ou menor probabilidade de perda
13
. Desta forma, um roteador
congestionado vai dar mais prioridade aos pacotes, de uma certa classe, que tiverem os
menores valores de precedncia de descarte.
A partir da Tabela 3-1, dos bits CCCDD0, CCC representa a codificao da
classe de servio, que ir determinar a fila de transmisso do pacote, e DD codifica o nvel
de precedncia do pacote dentro das classes.
0 1 2 3 4 5
C C C D D 0
DSCP
Tabela 3-1 Cdigos AF para classe de servio e nvel de precedncia
A Tabela 3-2 mostra, para cada grupo PHB AF, os valores dos DSCPs
recomendados pela RFC 2597[35].
Precedncia
de descarte
Classe AF1 Classe AF2 Classe AF3 Classe AF4
Nvel 1 (baixa) 001010 010010 011010 100010
Nvel 2 (mdia) 001100 010100 011100 100100
Nvel 3 (alta) 001110 010110 011110 100110
Tabela 3-2 Valores DSCP definidos pela RFC 2597
Para cada uma das classes, so alocados, nos roteadores, certos nveis de
recursos de rede, como largura de banda e armazenamento (buffers). Congestionamentos
ocorrem quando os roteadores recebem uma carga de trfego maior do que sua capacidade
de trat-los, o que poder exceder os limites de armazenamento e levar a um cenrio em
que o roteador dever decidir quais pacotes sero descartados. Nesses casos, o nvel de
precedncia do pacote que ir determinar a probabilidade de seu descarte.
O condicionamento de trfego o responsvel pela marcao do pacote em um
dos doze cdigos recomendados pelo IETF, de acordo com o resultado da medio. Um
perfil associado a cada trfego define o servio esperado por ele. Se, na chegada do
domnio DS, os pacotes estiverem em conformidade com o perfil para eles contratado, os
mesmos tero, enquanto a agregao no exceder a taxa contratada definida no perfil de
servio, alta probabilidade de ser entregues. Esses pacotes usaro recursos suficientes e
sero marcados com nveis baixos de precedncia para descarte. Caso contrrio, ou seja, se

13
O nvel de precedncia determina a importncia do pacote.

33

os pacotes no estiverem em conformidade com o perfil contratado
14
, eles provavelmente
sero rebaixados no nvel de classificao, sendo marcados com nveis de descarte mais
elevados e, portanto, tero menores probabilidades de serem encaminhados. Dependendo de
suas marcaes atuais, os pacotes j sero imediatamente descartados. Mecanismos de
descarte de pacote baseados em nveis de precedncia e em classes, como o GRED[38], so
adequados para a implementao dos grupos AF.
3.3.2 Encaminhamento Expresso (PHB EF)
O PHB EF a verso de DiffServ para encaminhar trfego de aplicaes
multimdia e de tempo real. Neste tipo de servio no h reclassificao de pacotes, como
no servio assegurado. Ou seja, os pacotes que no estiverem dentro do perfil contratado
sero obrigatoriamente descartados, sem possibilidade de remarcao.
Como j abordado inicialmente nesta sesso, o servio expresso caracteriza-se
pelos baixos valores de perda, jitter e atraso, o que significa dizer que, em cada n do
domnio DS, os pacotes agregados encontraro as filas dos roteadores vazias ou com
pequenas taxas de ocupao. Para alcanar isto, o n com PHB EF deve garantir que a
agregao de fluxos receba, em qualquer instante, uma taxa de chegada inferior taxa
contratada, independentemente da intensidade de outros trfegos que cheguem ao n.
Para permitir a essncia do servio expresso no interior de um domnio DS,
como no da Figura 3-2, ou seja, que a taxa de chegada da agregao EF aos ns internos
desse domnio esteja em conformidade com a taxa que foi contratada, os roteadores de
entrada (INGRESSO) tm papel fundamental. So eles que precisam condicionar o trfego
expresso que chega ao domnio DS, de forma a minimizar recondicionamentos naqueles
pontos internos EF e permitir, conseqentemente, que a definio do PHB seja vlida a
qualquer instante e em todo o percurso dos fluxos. Engenharia de trfego, s vezes,
necessria, porque trfego agregado, vindo de vrios roteadores de fronteira de entrada, se
aglomera nos roteadores internos, formando novas agregaes.

14
Exceder a largura de banda a eles associada, por exemplo.

34

O encaminhamento expresso pode ser implementado num domnio DS atravs
da aplicao de disciplinas de escalonamento com enfileiramento prioritrio (Priority
Queuing PQ), com limitao de taxas nas classes. Nesse caso, muito importante o
controle de trfego na fronteira do domnio, para evitar que fluxos EF, injustamente,
excedam na utilizao dos recursos, em detrimento atuao do trfego menos prioritrio
(como os de melhor esforo e classes AF). E isto pode ocorrer, principalmente, se a
disciplina aplicada for a prioritria de cunho estrito. Escalonadores, como PQ, sero
abordados mais adiante.
3.4 Diffserv em ambiente Linux
O ncleo do sistema operacional Linux j inclui um conjunto flexvel de funes
de controle de trfego, tornando-o propcio para a realizao de trabalhos experimentais na
rea de qualidade de servio. O princpio bsico envolvido no suporte a essas funes pode
ser observado na Figura 3-6, em que o ncleo do sistema processa os dados recebidos da
rede e gera novos dados para serem encaminhados.

Figura 3-6 Princpio bsico de controle de trfego no Linux
A funo de encaminhamento a responsvel em selecionar a interface de
sada aos pacotes que entram no n. Quando enfileirados, os pacotes passam a ser
monitorados pelo mdulo de controle de trfego (aplicao TC Linux Traffic Controller
[38][39]), que pode decidir, por exemplo, se os pacotes sero descartados; quais suas
prioridades no encaminhamento e quando envi-los (motivado pela funo de suavizao do
trfego).
Quatro componentes enfocam a arquitetura de controle de trfego no Linux:
! Disciplinas de servio (ou qdisc);
! Classes;

35

! Filtros;
! Policiamento.
Muito sinteticamente, j que no o objetivo deste trabalho aprofundar esses
conceitos, uma disciplina de servio deve estar sempre associada a um dispositivo de rede.
As mais complexas disciplinas, podem, no entanto, conter classes, tendo os filtros como os
responsveis pela atribuio dos pacotes s classes correspondentes e pela atribuio de
prioridades de uma classe em relao s outras. O controle de trfego em Linux dito
flexvel porque, a princpio, as classes no obrigatoriamente mantm as filas. Elas podem
anexar outra disciplina de servio
15
, que, por sua vez, pode, por exemplo, ter outra classe e
esta, finalmente, manter uma fila de pacotes. uma hierarquia de componentes, como se
pode observar na Figura 3-7.
O policiamento pode, sobre os fluxos que excederem os limites, manipular
pacotes nas filas, de acordo com determinadas aes. Tais aes podem ser a eliminao e a
remarcao de pacotes.

Figura 3-7 Exemplo de uma simples disciplina de servio no Linux, com vrias classes.

3.4.1 Disciplinas de escalonamento
Sero sucintamente abordados, a seguir, aspectos de alguns tipos de
escalonadores de pacotes, que so, inclusive, implementados no cdigo do Linux e
utilizados na plataforma de testes deste trabalho. As sintaxes e os detalhes de uso dessas
disciplinas no Linux so amplamente abordados em [41] e [42].

15
Disciplina de servio interior.

36

a) First In First Out (FIFO)
Conforme [40], enfileiramento do tipo FIFO a mais bsica disciplina de
escalonamento, onde todos os pacotes so tratados da mesma forma (sem prioridades de
uns sobre os outros), sendo os mesmos colocados numa nica fila e servidos na mesma
ordem em que so enfileirados.
O enfileiramento FIFO tem como vantagens a simplicidade e uma baixa carga
computacional. No entanto, no toma decises sobre prioridades dos pacotes e, por isso,
imprprio para aplicaes de tempo real, uma vez que, em casos de congestionamentos,
tende degradar as mtricas de QoS (atrasos, jitters e perdas de pacotes) dessas aplicaes.
No Linux, a disciplina FIFO apresentada em duas verses: pfifo e bfifo. No
primeiro caso, a fila limitada pelo nmero de pacotes e, na segunda opo, pelo nmero
total de bytes de todos os pacotes na fila.

b) Enfileiramento baseado em classes (CBQ Class-Based Queuing)
O CBQ prov o particionamento e o compartilhamento da largura de banda
disponvel num link, atravs do uso de classes hierarquicamente estruturadas, onde cada
classe ter sua prpria fila e receber uma fatia da banda. Ou seja, os pacotes
pertencentes s aplicaes so, baseados num esquema de pesos e prioridades, classificados
em vrias classes de servio e, ento, associados a uma fila, que especificamente dedicada
quela classe de servio. Para as classes com a mesma prioridade, as respectivas filas so
servidas na ordem conhecida como round-robin, em que, para transmisso, as filas so
percorridas de forma circular. transmitida ento, a partir de cada fila, uma quantidade de
trfego proporcional ao peso que lhe foi atribudo. Desta forma, pode-se garantir, com
CBQ, a maior parte da largura de banda do link a certas aplicaes, consideradas mais
crticas, com a parte remanescente sendo disponibilizada ao restante do trfego. Alm disso,
na estrutura hierrquica, uma classe filha pode emprestar largura de banda da classe me,
desde que haja banda disponvel.

37

O CBQ uma soluo consideravelmente razovel quanto ao compartilhamento
de banda passante pelas classes de servio. A possibilidade de se particionar, de forma
hierrquica, o trfego em tipos distintos de classes de servio, torna a disciplina cbq a mais
flexvel das atualmente implementadas no ncleo do Linux[42]. No entanto, o CBQ no
um mtodo simples de enfileiramento e, por isso, apresenta problemas de sobrecarga
computacional. Na implementao do Linux, por exemplo, isso percebido,
especificamente, durante as atividades de classificao de pacotes, de determinao das filas
a serem servidas e dos clculos de estimativa de banda a ser usada pelas classes do tc, o que
pode gerar degradao das mtricas de qualidade de servio.

c) Enfileiramento justo do tipo SFQ (Stochastic Fairness Queuing)
O SFQ uma simples implementao da famlia de algoritmos de enfileiramento
justo, sendo projetado para garantir que cada fluxo tenha um acesso justo aos recursos da
rede e, tambm, para evitar que fluxos variveis (em rajadas) consumam mais largura de
banda que os demais. Ou seja, o SFQ no visa diferenciao de servio entre os pacotes. Ao
contrrio, distribui eqitativamente a largura de banda aos fluxos do link. Logo,
teoricamente, o SFQ no seria prprio para trfego de voz, o que poder ser confirmado
mais adiante, nos testes experimentais realizados em laboratrio.
Com SFQ, os pacotes so inicialmente classificados em fluxos pelo sistema e,
depois, associados a uma fila, do tipo FIFO, que passa a ser dedicada quele fluxo. As filas
ativas
16
so servidas de forma circular (round-robin), sendo transmitido um certo volume de
dados de cada fila em cada passagem do algoritmo. O SFQ chamado estocstico porque
ele implementa algoritmo com funo hash, que divide o trfego num nmero limitado de
filas e as associa aos pacotes de cada fluxo.
A vantagem da disciplina que, dentre os escalonadores justos, a que requer
menos clculos[41], imprimindo uma baixa carga computacional. No entanto, o SFQ
apresenta limitaes. Uma delas a possibilidade de que a funo hash possa selecionar a
mesma fila para mais de um fluxo (colises), prejudicando a eqidade da disciplina. Uma
vez que isso acontea, os fluxos selecionados para o mesmo valor de hash sero tratados

38

injustamente, como se fossem um fluxo apenas. Isto ocorre quando o nmero de fluxos
ativos se aproxima do nmero de filas disponibilizado pela disciplina, que, no Linux,
limitado em 128 filas.

d) Enfileiramento prioritrio (Priority Queuing - PQ)
O escalonamento por prioridades, como o nome mesmo sugere, foi desenhado
para que, dentre vrias filas, o encaminhamento seja realizado a partir da atribuio de
prioridades a cada uma delas. Trata-se de um mtodo simples para suportar servio
diferenciado, em que os pacotes so inicialmente classificados e associados a filas com
diferentes nveis de prioridade.
H duas implementaes desta disciplina: a primeira a estrita, em que
somente sero transmitidos pacotes de uma certa fila quando todas as de prioridade
superior estiverem ociosas (vazias); a segunda a controlada por taxa[40], a qual permite
que pacotes de uma fila mais prioritria somente sejam encaminhados antes que os de uma
fila com menor prioridade quando o volume de trfego da mais prioritria estiver abaixo de
um certo limite configurado pelo usurio. Usou-se, nos estudos experimentais, o
enfileiramento prioritrio estrito, que apresenta como desvantagem a possibilidade de fluxos
mais prioritrios alocar todo o recurso de banda disponvel no link, impedindo, ou pelo
menos dificultando, a transmisso de fluxos de menor prioridade. No entanto, o PQ tem a
vantagem de, por efetuar apenas classificao de pacotes, apresentar baixa carga
computacional, sendo reconhecido como um algoritmo simples e eficiente na diferenciao
de trfego.
No Linux, a disciplina prioritria conhecida como prio, a qual implementa um
escalonador de prioridade estrita, com um nmero de bandas (filas)
17
configurvel pelo
usurio. Por default, na construo da disciplina, 03 classes automaticamente so criadas e,
em cada classe dessa, uma fila FIFO anexada
18
. Quando um pacote chega numa interface
de rede com a disciplina prio, h o processo de classificao e o mesmo encaminhado para
uma das filas FIFO criada. Para extrair um pacote da fila, as classes mais prioritrias sero

16
As filas que tm pacotes pendentes para serem transmitidos.
17
Quanto maior a identificao da banda, menor ser a prioridade.

39

sempre varridas primeiro e as bandas maiores somente sero visitadas quando no houver
pacotes nas bandas mais prioritrias. No entanto, se um pacote menos prioritrio estiver
sendo servido no momento da chegada de um mais prioritrio, este dever aguardar a
transmisso do primeiro.
A Figura 3-8 ilustra a estrutura automaticamente construda no Linux aps a
incluso de uma disciplina de fila prio, na qual se tem 3 bandas, cada qual correspondendo
a uma fila, sendo a banda superior a mais prioritria e a inferior a com menor prioridade
para ser servida.

Figura 3-8 Estrutura bsica da disciplina prio no Linux

3.5 Voz sobre IP como uma aplicao diferenciada
O entendimento do tipo de trfego gerado e o comportamento das aplicaes
so aspectos importantes para se determinar o modelo de QoS a ser disponibilizado aos
usurios.
Voz sobre IP uma aplicao sobre a qual ainda gerada uma grande
expectativa, considerando que j se consegue reduzir custos com telefonia e proporcionar
melhores qualidades no uso da voz em redes locais e remotas. Para isso, vrias tcnicas de
codificao para telefonia e para pacotes de voz tm sido padronizadas pelo ITU-T na srie
G, com taxas de gerao que podem variar de 5.3Kbps
19
a 64Kbps
20
, dependendo do tipo
de codificador/decodificador de voz (vocoder) utilizado. Dentre esses, pode-se mencionar

18
Pode-se substituir as filas FIFO por outras estruturas de enfileiramento.
19
Taxa gerada, para um nico fluxo, por codificador de voz do tipo G.723.1.
20
Taxa gerada, para um nico fluxo, por codificador de voz do tipo G.711.

40

aqui
21
o G.711, que, para comprimir, descomprimir, codificar e decodificar a fala, usa o
algoritmo PCM (Pulse Code Modulation), responsvel em gerar amostras de 8 bits a cada
0.125ms
22
, o que leva a uma taxa de 64Kbps
23
. padro tambm o G.726, que usa o
algoritmo ADPCM (Adaptive Differential Pulse Code Modulation) para codificar um fluxo
de bits G.711 em palavras de dois, trs ou quatro bits para gerar taxas de 16, 24, 32 ou
40Kbps[30, 43]. Recentes codificadores promovem uma drstica reduo na taxa de
gerao, s custas de adicional complexidade e atrasos na codificao, alm de apresentar
baixa qualidade[44]. Como exemplos, tem-se o G.729, com taxas de 8Kbps, e o G.723.1,
que gera os pacotes a uma taxa de 6.4Kbps. H vrios vocoders disponibilizados
atualmente, haja vista serem utilizados apropriadamente para lidar com as mais adversas
condies da rede. Pode-se, por exemplo, adotar um certo vocoder num link que apresente
altas taxas de perda ou atrasos elevados.
Cada vocoder fornece som com uma certa qualidade, que subjetiva porque
depende da preferncia de cada pessoa. Desta forma, a avaliao de conversaes sobre
redes IP pode ser feita atravs do nvel de opinio mdio (MOS - Mean Opinion Score),
que uma mtrica subjetiva comumente utilizada para isso e que expressa o julgamento dos
usurios, atravs de uma escala de 1 (ruim) at 5 (excelente). Dos vocoders julgados, o
G.711 o que alcana o maior ndice, com o MOS de 4.1 pontos. O vocoder G.726 tem a
opinio mdia de 3.85 pontos.
Os parmetros de QoS mais importantes para trfego de tempo real, como o de
VoIP, so os atrasos (delays), a variao desses atrasos (jitters) e a perda de pacotes. So
eles que vo determinar a qualidade dos fluxos de voz. O delay, por exemplo, pode dar
origem a ecos na recepo e, por isso, importante reduzi-lo ao mximo possvel, devendo-
se tambm empregar algoritmos de cancelamento de eco. Como os pacotes experimentam
atrasos diversos na rede, a variao do tempo de chegada desses pacotes no receptor
(atrasos entre os pacotes ou jitter) geralmente no constante, mesmo que o seja no lado
do transmissor. Por isso, como j mostrado anteriormente, a necessidade de utilizao de
buffers nos receptores, para uma reproduo mais contnua e fiel da voz. Quanto s perdas

21
Foram experimentalmente caracterizados neste trabalho, fluxos de voz gerados pelos vocoders G.726 e
G.711.
22
Conhecido como frame sizeou frame length, que o perodo de tempo necessrio para gerar um pacote
de voz.
23
A cada segundo so geradas 8.000 amostras de 1 byte, resultando em 8.000bytes/seg ou 64Kbits/seg.

41

de pacotes, taxas relativamente baixas podem ser toleradas, sem que haja grandes distores
na recepo. O nmero mximo de pacotes consecutivamente perdidos tambm uma
mtrica importante, sendo um fator que est diretamente relacionado com o maior perodo
durante o qual a voz perdida[45]. Referente a isto, conforme [46], para um fluxo de voz,
considerada aceitvel uma taxa de perda de pacotes de at 21% e um nmero mximo de 2
pacotes consecutivamente perdidos.
O atraso percebido num ambiente com VoIP , na verdade, gerado por uma
srie de pequenos atrasos, como o de gerao/formao do pacote e o de rede. O primeiro
diz respeito ao tempo gasto para amostrar a voz e gerar um pacote de dados que represente
a amostra gerada, sendo que est relacionado ao frame size mantido nos vocoders. J o
atraso de rede representa o tempo necessrio para o transporte do pacote, do terminal de
origem ao de destino, compreendendo o tempo de transmisso dos pacotes, atrasos com
roteamento e o tempo de permanncia dos pacotes nas filas dos roteadores da rede, que
podem se minimizados com a implementao de servios diferenciados. Ou seja, pode-se
perceber que os atrasos enfrentados pelos pacotes podem ter uma parte fixa e outra
varivel. A parte fixa a que no depende da carga da rede, mas, sim, do distanciamento
entre transmissor/receptor, da velocidade dos links e da capacidade dos elementos de rede
(memria e processamento, por exemplo). A parte varivel justamente aquela que resulta
do comprimento da fila e da carga momentnea da rede. Desta forma, a
diferenciao/priorizao do trfego no consegue interferir na parte fixa dos atrasos, mas,
o que mais importante, ajuda a minimizar sua parte varivel.
A recomendao G.114[47], do ITU-T, define, conforme mostra a Figura 3-9,
uma classificao de valores, em milissegundos, para a viabilidade do atraso em um sentido
(OWD) nas aplicaes de voz:
De acordo com o esquema a seguir, atrasos em um sentido de at 150ms so
perfeitamente aceitveis. No entanto, at 250ms, considera-se um atraso aceitvel,
pressupondo-se menor qualidade na conversao. Em ligaes internacionais, que envolvem
satlites, com maiores retardos, aceitvel um atraso de at 600ms[45].
Em aplicaes de voz, adotando-se somente o UDP como protocolo de
transporte, os pacotes podem tomar rumos distintos na rede e chegar fora da seqncia no

42

destino, o que seria resolvido caso se adotasse o TCP para verificar o seqenciamento e a
correo das mensagens. No entanto, em sua essncia, apesar do uso de aplicaes com
tecnologia P2P, como o Skype[63]
24
, o TCP no suporta transmisso de voz em tempo
real, porque utiliza mecanismo de recuperao dos dados perdidos por retransmisso. Ou
seja, no caso da perda de um pacote, por exemplo, a liberao dos dados para a aplicao
dever esperar por todas as retransmisses, o que acarretaria atrasos intolerveis. Desta
forma, as aplicaes de tempo real utilizam o UDP, ao invs do TCP, pela simplicidade e
menor sobrecarga que o primeiro tem sobre o segundo. O problema de seqenciamento
resolvido com o uso do UDP em conjunto com o protocolo RTP, definido pela RFC
1889[48], o qual prov servio de entrega fim-a-fim para dados com caractersticas de
tempo real, tais como udio e vdeo interativos.

Figura 3-9 Classificao da viabilidade de operao das aplicaes de voz, segundo o ITU-T.

A voz codificada montada em pacotes, que sero transportados pela rede,
utilizando-se os protocolos IP, UDP e RTP para realizarem esse transporte. Como j
comentado, por VoIP ser uma aplicao de tempo real, recomenda-se o uso conjunto
desses protocolos, haja vista a reduo do tempo perdido com confirmaes e
retransmisses.
Um pacote tpico de voz composto ento por cabealhos daqueles protocolos
e pela voz codificada em bits (parte tambm conhecida como frame de voz, carga til ou
payload), sendo que, os cabealhos, juntos, totalizam 40bytes
25
e contm informaes
necessrias para o transporte do pacote, como, por exemplo, endereos IP de origem e de
destino, portas de servios utilizadas, identificao do fluxo de voz, nmero de seqncia

24
O Skype pode utilizar portas TCP, com valores acima de 1024.
Excelente Bom Pobre Inaceitvel
0ms 150ms 300ms 450ms

43

do pacote, etc. importante salientar, no entanto, que, por questes de eficincia, j que os
frames de voz geralmente so pequenos, os pacotes podem carregar um ou mais desses
frames. Por exemplo, um pacote contendo voz com 24bytes
26
de carga til representa
apenas 37,5% de eficincia
27
. A soluo seria ento incluir vrios outros frames no mesmo
pacote, de forma a aumentar esta eficincia.
Pode-se utilizar, ainda, a tcnica de compresso de cabealho, que, como
introduzido em [62] e aperfeioado em [20], ajuda a aumentar a eficincia do RTP,
comprimindo os cabealhos RTP/UDP/IP de 40bytes para 2 a 4bytes. Tal compresso
especialmente benfica para pacotes pequenos em links muito lentos, com a reduo
significativa dos atrasos e da sobrecarga.
Este captulo concluiu as definies iniciais descritas no captulo anterior sobre
o modelo de servios diferenciados. Foram apresentados, alm dos elementos funcionais da
arquitetura e os aspectos acerca do condicionamento de trfego presentes num domnio
diferenciado, as formas de implementao de mecanismos de medio e policiamento de
trfego.
O captulo abordou como QoS pode ser visto pelo prisma de contratos entre os
usurios e os provedores de servio, a partir dos conceitos de acordo e de especificao de
nvel de servio (SLA e SLS, respectivamente). O conceito de PHB, um dos mais
importantes em DiffServ, tambm foi contextualizado, sendo reproduzidos os aspectos mais
importantes dos servios expresso (PHB EF) e assegurado (PHB AF).
Questes no Linux responsveis pelo controle e pela diferenciao de trfego
foram descritas neste captulo de uma forma bem sucinta, j que o aprofundamento do
assunto no objetivo deste trabalho. As disciplinas de escalonamento aplicadas no testbed
foram destacadas: FIFO, CBQ, SFQ e PQ.

25
20bytes para o IP + 8bytes para o UDP + 12bytes para o RTP.
26
o caso de pacote contendo voz no formato G.723.1.
27
Percentagem resultante a partir do seguinte clculo: (24/(24+40)*100), onde 24 o tamanho da carga til
(em bytes) e 40 (tambm em bytes) o tamanho do cabealho.

44

O captulo abordou, por fim, aspectos relacionados s aplicaes de voz sobre
IP, com nfase nos codificadores/decodificadores de voz (vocoders) caracterizados neste
trabalho: G.711 e G.726.

45

4. O ambiente de testes
Apresenta-se, neste captulo, o ambiente em que a fase experimental do trabalho
foi realizada. Sero mostrados a topologia da rede e o domnio diferenciado, assim como os
mtodos utilizados nos experimentos e as ferramentas de software adotadas no testbed.
4.1 Topologia da rede
A plataforma de testes composta por cinco microcomputadores Pentium, nos
quais foram instalados sistemas operacionais Linux
28
, com pacotes iproute2 e suporte
qualidade de servio (DiffServ). Mostra-se com isso que, num ambiente sem custos e sem
equipamentos sofisticados, composto apenas por microcomputadores, alguns dos quais
exercendo funes de roteadores, e por softwares livres
29
, se pde estudar o desempenho
de fluxos modelados de voz sobre IP com qualidade de servio, utilizando o modelo
diferenciado mais especificamente o encaminhamento expresso (PHB EF).
A Figura 4-1 mostra a topologia que se adotou, montada numa rede Ethernet
(IEEE 802.3 10BaseT/100BaseT) e disposta numa rea local e completamente controlada,
sem qualquer outro trfego presente nos links, os quais apresentam velocidades de 10Mbps
ou 100Mbps. Como o enfoque trabalhar com fluxos caractersticos de voz, que
geralmente ocupam muito pouca banda passante, e como cada fluxo desses representa um
programa em execuo no sistema operacional, seria completamente invivel preencher uma
parte representativa dos links com fluxos de baixas taxas. Seria necessria para isso uma
quantidade enorme de fluxos e, conseqentemente, um nmero imprprio de processos no
Linux competindo por recursos de mquina. Os resultados poderiam ser muito variveis e
duvidosos. Por exemplo, num link de 10Mbps, para se alcanar desse valor com fluxos
modelados de voz de 32Kbps (gerao caracterstica de um vocoder G.726), seria
necessrio utilizar-se setenta e oito fluxos de voz e, portanto 78 processos nas mquinas
geradoras. Como soluo para tal problema, teve-se que configurar o controlador de
trfego para limitar consideravelmente o link. Isto foi conseguido atravs da utilizao da

28
Distribuio RedHat verso 9, com kernel 2.4.31.
29
Os softwares livres utilizados nos experimentos foram os sistemas operacionais e as ferramentas de
suporte a trfego de rede, como os geradores, os analisadores e os medidores.

46

disciplina de servio cbq e ser mais bem abordado durante as explicaes dos
experimentos.

Figura 4-1 Topologia da rede
O domnio diferenciado tambm pode ser visualizado na figura acima.
Conforme explicado no Captulo 3, num domnio DS os roteadores podem executar, em
relao ao trfego, funes de condicionamento distintas. No caso do domnio montado no
testbed, os ns da rede exercem os seguintes papis:
a) As mquinas qos3 e qos4 no fazem parte do domnio DS e servem
exclusivamente para gerar trfego prioritrio (de voz), sem executar qualquer espcie de
marcao ou classificao nos pacotes.
Em testes onde so tratados atrasos na ordem de milissegundos, a quantidade
de processos sendo executados no sistema operacional de uma mquina pode influenciar
nos resultados finais. Ou seja, cada fluxo gerado representa um processo em execuo no
Linux. Logo, num cenrio onde precisam ser gerados, por exemplo, 32 fluxos de voz, em
vez de execut-los todos numa mesma mquina, sobrecarregando-a, mais seguro faz-lo
distribuindo os processos entre as mquinas geradoras. E exatamente por isso, para se
causar um balanceamento na carga total de gerao dos fluxos de voz e se chegar a
resultados mais confiveis, que foram adotadas duas mquinas para a mesma funo.
qos3
qos4
qos1 qos5
qos2
Roteador de
borda de entrada
(INGRESS)
Roteador interno e de
borda de sada
(EGRESS)
Geradores
de trfego
Medidor
de trfego
DOMNIO DIFERENCIADO
eth0
eth0
eth0
eth0
eth0
eth2
eth1
eth1
EF
EF
BE

47

b) A mquina qos1 opera como o roteador de entrada do domnio DS
(ingresso), sendo responsvel, essencialmente, pelas funes de marcao dos pacotes e
classificao MF dos fluxos gerados. Tais funcionalidades foram teorizadas no Captulo 3
deste trabalho. Alm disso, para perturbar o meio, qos1 realiza tambm a gerao de
trfego de fundo (melhor esforo ou apenas BE).
c) A mquina qos5 vista tanto como o roteador interno como o de fronteira
(tipo egresso) do domnio diferenciado. Ou seja, um n interno porque condiciona o
trfego vindo de um n ingresso e um roteador de fronteira porque, depois dele, nenhuma
outra mquina realiza qualquer condicionamento de trfego. O n qos5 ignora os dois bits
menos significativos do campo DSCP
30
e gera uma nova marcao nos pacotes,
classificando-os nica e exclusivamente atravs desse campo. Ou melhor, a mquina qos5
realiza classificao do tipo BA e, alm disso, onde, nos estudos experimentais, so
aplicadas as disciplinas de escalonamento, com vistas diferenciao de trfego.
d) A mquina qos2 sempre o destino dos pacotes. nela em que so feitos os
clculos e as medies de trfego, com base nos valores de QoS de interesse (delays, jitters,
taxas de perdas e de vazo).
4.2 Metodologia adotada
Para que se chegue a um trabalho experimental confivel, extremamente
importante que as etapas sejam previstas a partir de planejamentos constantes e que sejam
adotados mtodos e padres coerentes. Sero descritas nesta sesso quais mtricas de QoS
foram adotadas, como os resultados foram alcanados e os tipos de trfego utilizados, alm
de se abordar tambm a sincronizao de tempo na rede e as ferramentas de software
aplicadas no testbed.
4.2.1 Aspectos gerais
As mtricas de QoS colhidas para anlise no trabalho foram as consideradas
pela literatura como as mais relevantes para o estudo de voz em redes IP, que so o delay e

30
Sem uso pelos roteadores do domnio DS, conforme RFC 2474[23].

48

sua variao (jitter)[33][58]. Foram tambm investigadas as taxas de perda de pacotes e de
vazo.
Teve-se a preocupao de se seguir a base do modelo diferenciado, atravs do
estudo do comportamento de agregados de fluxos caracterizados de voz. Na verdade,
agregao uma palavra-chave em redes com DS, introduzida para aumentar a
escalabilidade da arquitetura. Neste contexto, dado o grande nvel de variaes dos
resultados e, portanto, a pouca confiabilidade alcanada, no se adotou medies em cima
de fluxo de referncia, muito utilizado em trabalhos de simulao, como em [45] e em [49],
por exemplo. Ao contrrio disso, as mtricas de QoS foram calculadas, para cada fluxo,
atravs da mdia aritmtica dessas medidas, avaliada sobre todos os pacotes daquele fluxo.
Como se est trabalhando com agregados de fluxos, os valores de uma repetio so
conseguidos, outra vez, pelo clculo da mdia aritmtica sobre os valores mdios de cada
fluxo, o que traz mais confiana e menos variaes dos resultados durante as demais
repeties de cada estudo experimental. Desta maneira, os testes foram repetidos vrias
vezes, de forma a garantir a validade estatstica dos resultados, os quais foram sumarizados
atravs do clculo da mdia aritmtica das mtricas sobre o total de 12 repeties. Tal
nmero foi considerado suficiente, diante das poucas variaes observadas entre os
resultados das repeties, uma vez terem sido realizadas, como j citado, num ambiente
controlado.
Na noo de servios diferenciados foram aplicados, sempre, o
encaminhamento expresso (PHB EF), para corresponder ao trfego modelado de voz, e o
melhor esforo (PHB default), relativo ao trfego de perturbao do meio. Ademais,
como forma de se aproximar da situao real, os fluxos de voz foram gerados, em todos os
testes, por fontes do tipo ON-OFF, com a utilizao do UDP como protocolo de
transporte. J para o trfego de fundo, foram empregados, dependendo da situao, os
protocolo UDP ou TCP, sendo o primeiro mais comumente presente nos estudos, uma vez
ter-se maior controle das taxas sendo geradas, j que a vazo resultante do TCP, por ser um
protocolo adaptativo, sempre depende das condies momentneas da rede, fugindo, de
alguma forma, do controle do autor.

49

4.2.2 Sincronizao do tempo
O estudo do tempo em que os pacotes percorrem de um lado a outro da rede
(atraso fim-a-fim em um sentido ou one-way delay) requer muita preciso nos relgios das
mquinas transmissoras e receptoras
31
. Isto ocorre porque as ferramentas que realizam tal
medio calculam o delay tomando como base a diferena numrica entre o tempo em que o
pacote chega no receptor e o tempo em que o mesmo transmitido
32
. Se os relgios das
mquinas envolvidas no processo de gerao/recepo do trfego estiverem alguns
milissegundos fora de sincronia, isso, com certeza, como observado em laboratrio, vai
influenciar significativamente nos resultados finais. Visando no se ter problemas dessa
natureza, configurou-se a rede para que, automaticamente, na virada de cada minuto, as
mquinas do testbed sincronizassem seus relgios, pois se percebeu que 1 minuto apenas j
era um tempo suficiente para desajustar, em pouqussimos milissegundos, os relgios dos
ns
33
. Foram usadas, para isso, as ferramentas ntpdate e at, prprias do sistema
operacional. Alm disso, elegeu-se a mquina qos1 como servidora de tempo (NTP server),
a quem as mquinas geradoras (qos3 e qos4) e receptora de trfego (qos2) solicitavam, a
cada minuto, sincronizao do tempo. Uma forma possvel de se obter a sincronizao
perfeita do tempo numa rede de computadores seria atravs de uma interface especial de
relgio baseada em GPS, que forneceria um padro de tempo global nico, com preciso.
No entanto, trata-se de um hardware incomum e com custos adicionais[50].
Ademais, ainda com relao sincronizao de tempo, percebeu-se, durante os
testes iniciais, dois fatos importantes: i) quando os experimentos foram disparados no incio
ou pouco alm do meio do minuto, os atrasos sofriam uma elevao muito discreta, pois
so momentos em que os relgios no estavam totalmente sincronizados
34
; ii) quando os
experimentos duraram mais de 60 segundos, os atrasos dos pacotes tenderam a uma certa

31
Principalmente neste testbed, pois, como a rede local e controlada, os valores de delay e jitter tendem a
ser inferiores aos encontrados em redes de longas distncias, com satlite, links de baixas velocidades,
roteamentos excessivos, etc.
32
Quando o pacote chega no destino marcado com um timestamp de recepo e quando o mesmo pacote
sai da mquina de origem ele rotulado com um timestamp de transmisso.
33
Isso percebido atravs do comando ntpdate, do Linux, que fora a sincronizao do tempo entre duas
mquinas na rede e que usa o protocolo NTP (Network Time Protocol).
34
Isso se d porque, nos primeiros momentos aps a sincronizao das mquinas (que ocorre na virada do
minuto), os relgios ainda no esto totalmente sincronizados. Logo, h um momento timo em que as
mquinas tm seus relgios sincronizados, mas, depois, aproximadamente no quadragsimo segundo do
minuto, as mquinas tendem a perder novamente a sincronizao total.

50

elevao, j que a virada do minuto um perodo crtico, pois o momento em que as
mquinas realizam a sincronizao do tempo, carregando discretamente a rede. A soluo
ento foi encontrar um momento timo para o incio de cada experimentao e fazer com
que os testes tivessem uma curta durao. Desta forma, padronizou-se que todo teste seria
inicializado no dcimo terceiro segundo do minuto e que duraria apenas 20 segundos.
4.2.3 Ferramentas de software
Para suporte fundamental realizao do trabalho, foram necessrias algumas
ferramentas de software, responsveis pela gerao, medio e anlise de trfego.
Os componentes mgen, drec e mcalc, da famlia MGEN[51], foram aplicados,
respectivamente, para a gerao, a recepo e a medio do trfego UDP. Foi atravs do
mcalc que se pde sumarizar os dados para a gerao dos grficos aqui apresentados e
analisados. O MGEN permite a gerao controlada de fluxos UDP, sendo possvel a
transmisso de trfego unicast ou multicast, a partir da taxa de bits desejada. A ferramenta
permite ainda controlar o tempo do experimento e a variao do tamanho dos pacotes UDP
estudados, alm de aplicar a noo de host time, definida em [28], em que h o registro
do timestamp nos pacotes imediatamente antes de serem transmitidos na rede e assim que
sejam recebidos no destino. Os dois tempos servem, como j destacado mais acima, para
calcular o OWD. As verses do MGEN utilizadas nos testes foram a 3.2 para o componente
drec e a 3.0 para o componente mgen
35
, j que, com trfego do tipo ON-OFF, a execuo
do mgen 3.2, sempre usada por meio de scripts, abortava com falhas de segmentao.
Trabalhou-se com o mcalc 3.2 para o processamento dos valores mtricos de QoS.
Especificamente para o uso de trfego do tipo TCP, utilizou-se o
NETPERF[52], definido como uma ferramenta de benchmark, desenvolvida pela diviso de
redes da Hewlett-Packard Company e til para medir aspectos de desempenho de rede. O
NETPERF satura o meio e retorna a vazo alcanada pelo fluxo analisado, sendo composto
por dois programas bsicos: netperf e netserver. A ferramenta baseada no esquema
monitor-refletor, onde o trfego gerado numa estao (a com o netperf), transmitido
para o n destino (o com o netserver), refletido e retornado estao transmissora, a qual

35
Mesmo numa rede muito bem sincronizada, a verso 3.0 do drec apresentou valores de delay e jitter
incoerentes e muito elevados.

51

apresenta os resultados. Tal esquema especialmente necessrio em testes onde se deseje
calcular atrasos de ida-e-volta dos pacotes
36
, com menos custos. Significa dizer nesse caso
que a maior carga de processamento se restringe no lado transmissor (monitor) dos dados,
com o lado refletor efetuando apenas a funo de retransmisso dos pacotes, sem qualquer
processamento extra de informao. A verso do NETPERF aqui empregada foi a 2.2.
A anlise de rede foi realizada atravs da ferramenta tcpdump[53], indispensvel
para um acompanhamento preciso dos pacotes durante os experimentos e para a obteno
de concluses importantes. utilizada, algumas vezes, para confirmar tamanho dos pacotes
(heads e paylods) e para computar o nmero total de pacotes e a vazo. Com tcpdump, os
dados so capturados durante as sesses de testes e analisados aps o processamento, em
arquivos de registro (log).
Por fim, para o controle de trfego, como j sinalizado anteriormente, utilizou-
se a ferramenta tc do Linux, ao nvel de usurio, para dar o suporte suficiente e necessrio
aos servios diferenciados, basicamente criando-se e associando-se filas aos dispositivos de
sada de rede.
Foram abordados, neste captulo, itens importantes referentes ao ambiente de
testes. A topologia de rede, disposta numa rea local e controlada, e o domnio
diferenciado, foram apresentados, especificando-se as funes de condicionamento de cada
n do testbed.
Definiu-se a metodologia utilizada nos testes, descrevendo-se a forma de
clculo das mtricas de QoS e os servios DiffServ utilizados.
Apresentou-se tambm como o tempo na rede foi tratado, destacando-se a
importncia da sincronizao entre as mquinas para o alcance de resultados confiveis.
Finalizou-se o captulo com a exposio das ferramentas de software adotadas
nos experimentos.

36
Conhecido como round-trip delay.

52

Mostram-se, nos prximos captulos, detalhes dos estudos experimentais
realizados na plataforma de testes e as anlises correspondentes aos valores extrados.

53

5. Modelagem de vocoders de udio
Teve-se como primeira preocupao, antes mesmo de qualquer tipo de
modelagem, a certificao de que o ambiente de testes montado era capaz de prover QoS,
com diferenciao de servio entre classes, atravs da aplicao, no roteador interno
(QoS5), de disciplinas de escalonamento de trfego. Concebeu-se, ento, um estudo
experimental para isso, determinado como pr-requisito para os demais estudos.
O intuito desse primeiro estudo era tambm comparar os valores mtricos de
QoS entre as implementaes, sendo empregados trs tipos de escalonadores disponveis no
Linux: prio, sfq e pfifo. Para cada caso foi reservada, atravs da criao de uma disciplina
de servio cbq e de uma classe (tambm cbq) a ela instalada, a banda passante de
2.048Kbps no roteador interno e, sob tal disciplina, foram aplicados os escalonadores
correspondentes. Ou seja, no primeiro caso, instalou-se a disciplina prio na classe cbq j
criada, utilizando-se duas bandas
37
(das trs criadas automaticamente[41]) para o
escoamento dos fluxos e, em cada banda dessa, anexou-se uma fila crua do tipo FIFO, com
limite de 10 pacotes em cada uma. Para o caso da disciplina sfq, esta foi anexada
diretamente na classe cbq, com os fluxos sendo classificados, cada um, para uma das 128
filas criadas automaticamente[42] e escalonados, em ordem round-robin, por meio de
algoritmo de hashing. A opo quantum
38
utilizada foi a default do sistema (1.514bytes) e o
valor da opo perturb
39
escolhido foi de 15 segundos
40
. vista como uma disciplina
projetada para garantir que cada fluxo tenha um acesso justo aos recursos da rede,
prevenindo que rajadas de um fluxo monopolizem a rede, sendo este o motivo pelo qual a
disciplina sfq no aconselhada para trfego de tempo real. Por fim, para a disciplina pfifo,
fez-se algo semelhante, anexando-a classe cbq criada e configurando-a para comportar o
limite mximo de 20 pacotes. Neste caso, os pacotes dos fluxos concorrem na mesma fila,
sem qualquer tratamento especial. Pode-se ver a utilizao deste escalonador como a
ausncia de QoS na rede.

37
A banda 0 foi direcionada para o trfego mais prioritrio e a banda 1 para os pacotes de menor
prioridade. Como j se sabe, o PRIO age com prioridade estrita, na qual os pacotes direcionados para as
bandas mais altas (de menor prioridade) somente so servidos quando no houver trfego nas bandas de
maior prioridade.
38
Especifica a quantidade de bytes que pode ser enviada, de cada fila, durante a passagem do round-robin.
39
Introduz perturbao peridica no clculo de hash, para evitar colises de pacotes.
40
Em testes preliminares, percebeu-se que, quanto maior o valor desta opo maior os valores de atrasos e
jitters encontrados. Escolheu-se ento um valor abaixo da durao dos testes.

54

Como o objetivo era fundamentalmente o de mostrar a capacidade do testbed
de poder diferenciar trfego, foram injetados na rede 02 fluxos exatamente idnticos, tendo,
cada um deles, as seguintes caractersticas: UDP como protocolo de transporte; pacotes
com carga til de 520bytes; fonte geradora do tipo contnua (CBR) e agregado composto
por oito fluxos de 160Kbps (38.5 pacotes por segundo pps) cada um, com taxa total de
gerao de 1.280Kbps. Utilizou-se, para isso, a ferramenta mgen, responsvel pela gerao/
medio dos agregados.
Os grficos da Figura 5-1 e da Figura 5-2 exibem, para cada disciplina, os
respectivos valores de atraso e jitter mdios alcanados pelos dois fluxos idnticos injetados
na rede, com um deles representando o fluxo de voz e o outro o fluxo de melhor esforo
(BE).
Valor Mdio de Delay
0.00
50.00
100.00
150.00
200.00
250.00
300.00
350.00
D
e
l
a
y

(
m
s
)
Voz 8.25 54.25 201.00
BE 43.33 55.25 227.58
Disciplina prio Disciplina pfifo Disciplina sfq

Figura 5-1 Valor mdio de delay
V-se, claramente atravs dos valores obtidos, como a disciplina prio consegue
tratar, diferentemente, ambos os fluxos, priorizando estritamente o de voz em detrimento ao
de melhor esforo. O trfego BE com prio tem, ainda assim, conseguido melhor
desempenho do que os fluxos de voz e de fundo das demais disciplinas (pfifo e sfq), dada a
eficincia com que os pacotes de voz so encaminhados com a disciplina prioritria. Ou
seja, os valores de BE com prio so baixos (em relao aos valores das demais disciplinas)
porque os nmeros referentes voz j so significativamente pequenos.

55

Valor Mdio de Jitter
0.00
50.00
100.00
150.00
200.00
250.00
300.00
350.00
J
i
t
t
e
r

(
m
s
)
Voz 11.27 57.58 296.08
BE 49.50 58.08 325.75

Figura 5-2 Valor mdio de jitter
Chama a ateno tambm a proximidade dos valores de voz e BE nas disciplinas
pfifo e sfq, explicada pela eqidade no tratamento dado aos fluxos. No caso do pfifo, isto
traduzido pela competio dos pacotes dos fluxos pelos espaos (20 pacotes) de uma
mesma fila. J no caso do sfq, os valores prximos so confirmados pela natureza justa com
que os fluxos so tratados. Os valores bastante elevados com sfq foram alcanados, muito
provavelmente, por causa da configurao da disciplina, mais especificamente devido ao
grande tamanho de cada fila (128 pacotes
41
), elevando os atrasos e suas variaes. Ademais,
a variao do limite da fila com pfifo tambm influi diretamente nos valores de jitter e delay.
Adotou-se o limite de 20 pacotes para efeito de comparaes, j que a disciplina prio,
embora em 2 filas, como j descrito, igualmente apresenta 20 pacotes.
As figuras a seguir mostram os grficos relativos s taxas de perdas de pacotes
e de vazo conseguidas por cada uma das disciplinas testadas. Destaca-se, na Figura 5-3, a
percentagem de pacotes perdidos na banda 0 (referente voz) da disciplina prio.
Demonstrando, outra vez, a eqidade com que os fluxos so tratados, v-se a
proximidade das taxas alcanadas com sfq e pfifo.

41
Este limite pode ser alterado, mas apenas no prprio cdigo-fonte, antes da compilao[42].

56

Valor Mdio de Perda
0.00
5.00
10.00
15.00
20.00
25.00
30.00
T
a
x
a

d
e

P
e
r
d
a

(
%
)
Voz 0.00 9.44 8.68
BE 20.70 10.88 10.11

Figura 5-3 Taxa de perda de pacotes.
Estabeleceu-se, em todo o trabalho, que, para vazo, a mtrica adotada no
seria simplesmente o valor da vazo atingido pelos fluxos, mas, sim, a razo entre este valor
e a taxa gerada para os fluxos. Isto se deu porque h experimentos que comparam cenrios
em que as taxas de gerao so distintas, dada, principalmente, natureza de trfego do
tipo ON-OFF, como poder ser percebido mais adiante. Tal mtrica ficou definida como
taxa de vazo alcanada.
A Figura 5-4 mostra os resultados conseguidos pelas disciplinas e,
curiosamente, percebe-se que a imagem inversa da taxa de perdas. A princpio, possvel
compreender-se que quanto maior a vazo alcanada por um fluxo menor ser a
resistncia (perdas) que o mesmo vai enfrentar em seu percurso, e vice-versa. Talvez o que
no seja bvio que isso se desse de uma forma inversamente proporcional, como mostrou
os resultados.
Tendo-se provado que o ambiente de teste capaz de diferenciar trfego,
atravs da aplicao e configurao de disciplinas de servio como o prio, partiu-se para
estudar os efeitos alcanados por fluxos modelados de udio, caractersticos de diferentes
tipos de codificadores/decodificadores de voz, com a variao de tamanhos de pacotes e
nmero de fluxos agregados prioritrios. Foram modelados fluxos ON-OFF caractersticos
dos seguintes vocoders:

57

a) G.726, com frame size de 30ms, respectivos pacotes com tamanhos de 120bytes
e fluxos ON-OFF gerados a uma taxa de 32Kbps
42
cada um;
b) G.711, com frame size de 25ms, respectivos pacotes com tamanhos de 200bytes
e fluxos ON-OFF gerados a uma taxa de 64Kbps cada um;
c) G.711, com frame size de 65ms, respectivos pacotes com tamanhos de 520bytes
e fluxos ON-OFF gerados, tambm, a uma taxa de 64Kbps cada um.
Valor Mdio - Vazo Alcanada
70.00%
75.00%
80.00%
85.00%
90.00%
95.00%
100.00%
T
a
x
a

d
e

V
a
z
o

A
l
c
a
n
a
d
a

(
%
)
Voz 100.00% 90.41% 90.91%
BE 79.28% 89.07% 88.96%

Figura 5-4 Taxa de vazo alcanada.
primeira vista pode-se imaginar que os tamanhos dos frames so grandes
demais para representar VoIP. Na verdade, a escolha se deu em funo de uma limitao do
ambiente de testes, j que, se fossem empregados frames bem menores
43
, isso acarretaria na
necessidade de um nmero proporcionalmente maior de fluxos e, conseqentemente, de
mais processos Linux. Como j citado, isso comprometeria os resultados.
Os fluxos de voz foram testados no intervalo de 20 segundos, sendo que os
momentos ON-OFF foram respeitados seguindo, para cada segundo de teste, 400ms de
atividade e 600ms de silncio. Como no se controla a quantidade exata em geraes com
fluxos do tipo ON-OFF, foram usadas taxas com percentagens proporcionais, onde, para

42
Em momentos de atividade de cada fluxo gerado.
43
Se fosse modelado o vocoder G.729, por exemplo, os fluxos deveriam ser gerados a uma taxa de apenas
8Kbps cada um. Isso significa que, para um estudo comparativo em relao ao vocoder G.711, seria
necessrio gerar 8 fluxos (processos Linux) G.729 para equivaler a 1 fluxo G.711.

58

cada tipo de vocoder analisado, as taxas de gerao de voz ficaram em 20% do total
gerado, com o restante (80%) sendo preenchido por trfego de melhor esforo (BE). Para
esclarecer essas propores, a Tabela 5-1 mostra, para cada tipo de vocoder, a vazo de
cada fluxo ON-OFF, quantos fluxos foram necessrios gerar e as diferentes vazes dos
agregados alcanadas, com todas discretamente acima da linha dos 500Kbps. Os valores
referentes aos fluxos de fundo (BE) tambm so mostrados na Tabela 5-1, com as
respectivas vazes correspondendo a 80% da carga total da rede.
Tipo de
Vocoder

Taxa gerada
em 1 fluxo nos
momentos ON
Tamanho til
do pacote
(payload)
Vazo efetiva
em cada fluxo
N
o
de fluxos
utilizados
Vazo total
efetiva
44

Voz 32Kbps 120b 13.86Kbps 37 512.7Kbps
G.726 (120b)
BE (CBR) - 1470b 2.051Kbps 1 2.051Kbps
G.711 (200b)
BE (CBR) - 1470b 2.008Kbps 1 2.008Kbps
G.711 (520b)
BE (CBR) - 1470b 2.042Kbps 1 2.042Kbps
Tabela 5-1 Vazo agregada por vocoder.
Com base nos valores de gerao, estabeleceram-se, tambm
proporcionalmente, os valores de reserva de banda, configurados no roteador interno
atravs da disciplina cbq, partindo-se do princpio de se limitar aproximadamente
2.048Kbps para uma gerao conjunta em torno de 512Kbps para voz e 2048Kbps para
trfego de melhor esforo
45
. Dessa regra bsica, tm-se as reservas na Tabela 5-2.
Tipo de
Vocoder
Reserva de banda em QoS5 (Kbps), atravs
da configurao da disciplina cbq
G726-120b 2.050,96Kbps
G711-200b 2.008,00Kbps
G711-520b 2.042,07Kbps
Tabela 5-2 Reservas de banda no roteador interno do domnio DS.
O estudo comparou o desempenho dos fluxos de voz sobre dois tipos de
escalonadores Linux: prio e bfifo. No primeiro caso, anexou-se ao prio, nas bandas de voz
e de melhor esforo, filas do tipo FIFO, limitada por bytes
46
(tipo bfifo) e fixadas em
1.600bytes para voz e 14.700bytes para o trfego default. No segundo caso, com a

44
Valor conseguido com a ausncia de mecanismos de diferenciao de servio.
45
Ver valores da coluna Vazo total efetiva, da Tabela 5-1.
46
Em testes com filas FIFO do tipo pfifo, anexadas s bandas do prio, no foi possvel observar-se
diferenciao nos valores de atraso entre os vocoders, j que a variao dos tamanhos dos pacotes no
influenciou nos resultados, porque o limite da fila era fixo e estipulado por pacotes. Por exemplo, numa

59

disciplina bfifo, estabeleceu-se, para efeito de comparaes com a disciplina prioritria, o
tamanho da fila nica FIFO fixada em 16.300bytes, que corresponde soma dos tamanhos
das duas bandas utilizadas com prio (ou seja, 1.600 + 14.700). importante frisar tambm
que o uso da disciplina bfifo serve para representar a ausncia de qualidade de servio, j
que, nela, no h qualquer tratamento especial ou diferenciado. Os resultados sero
mostrados nas prximas sesses.
5.1 Aplicao da disciplina prio
5.1.1 Estudo do delay
Observando-se a Figura 5-5, percebe-se que o atraso dos agregados de voz
aumenta discretamente com o tamanho dos pacotes. Esse crescimento causado,
basicamente, pela variao do tamanho dos pacotes em estudo e pela priorizao do trfego
de voz.
A variao no tamanho dos pacotes afeta diretamente no atraso de gerao e,
conseqentemente, no tempo em que esses pacotes vo gastar para alcanarem o n
receptor (conhecido como atraso de transmisso). Deve-se perceber que pacotes maiores
levam mais tempo para serem gerados e isso repercute no valor mdio de delay daqueles
pacotes. No caso em questo, conforme a Tabela 5-3, mantm-se praticamente o mesmo
valor da taxa de gerao do trfego BE, mas, medida que se aumenta o tamanho dos
pacotes modelados dos vocoders (G.726-120bytes, G.711-200bytes e G.711-520bytes
nessa ordem), diminui-se, necessariamente, a taxa de pacotes EF gerados por segundo.
Logo, aumenta-se o tempo de gerao (pela ferramenta MGEN) e de transmisso de cada
pacote de voz, o que contribui para elevao do atraso mdio desses pacotes.

pfifo limitada em 10 pacotes, com o aumento do tamanho dos pacotes a fila sempre ter os mesmos 10
pacotes, o que mantm, praticamente, os mesmos resultados.

60

Disciplina prio (Voz)
8.000
9.000
10.000
11.000
12.000
13.000
14.000
15.000
D
e
l
a
y

(
m
s
)
Voz 8.500 8.583 8.667
G726-120bytes G711-200bytes G711-520bytes

Figura 5-5 Delay de voz com a disciplina prio.
Alm disso, sabe-se que, com a disciplina prio, os pacotes EF so classificados
para a banda mais prioritria e escalonados imediatamente para transmisso enquanto
houver pacotes na fila correspondente (forma estrita). H, com isso, um nvel mnimo de
concorrncia com o trfego de fundo, mesmo que este tenha probabilidade de ser servido, j
que os agregados de voz so do tipo ON-OFF e, em momentos de silncio desses fluxos, o
trfego BE aumenta suas chances de ocupar a fila de transmisso
47
. Mesmo assim,
entretanto, a afluncia inibe a atuao dos pacotes de melhor esforo.
Atrasos com gerao de pacotes

Nmero de pacotes efetivamente
gerados por segundo (pps)
48

Tipo de
Vocoder
Agregado de Voz
(ON-OFF)
Fluxo BE (CBR)
Tempo para gerar 1
pacote EF (ms)
Tempo para gerar 1
pacote BE (ms)
G726-120b 517.55 174.40 1.93 5.73
G711-200b 303.87 170.75 3.29 5.85
G711-520b 119.50 173.64 8.36 5.75
Tabela 5-3 Atrasos de gerao de pacotes.
Com base nas linhas adotadas acima, pode-se concluir que, quanto menor o
tamanho dos pacotes: menos tempo ser gasto para se gerar cada pacote; para manter a

47
Estgio adicional de armazenagem de pacotes. Geralmente uma fila FIFO, limitada por nmero de
pacotes (configurvel pelo comando ifconfig do Linux) e localizada aps as decises de escalonamento do
sistema operacional (TC).
48
Valores reais mdios, extrados em cada experimento.

61

mesma carga na rede, mais pacotes sero injetados; os momentos de ociosidade da banda 0
(voz) sero menores; a possibilidade do trfego de fundo atrapalhar o encaminhamento dos
pacotes de voz ser menor; e, conseqentemente, os atrasos mdios de uma via sero
menores.
Em sntese, justificam-se os resultados extrados com prio pelo fato dos pacotes
maiores sofrerem tempos mais elevados para serem gerados e transmitidos na rede e,
tambm, em decorrncia dos pacotes de voz praticamente no enfrentarem concorrncia
com o trfego de perturbao.
A Figura 5-6 inclui, Figura 5-5, a linha dos fluxos de melhor esforo contnuos
(CBR), que, ao contrrio dos fluxos de voz, melhoram seus atrasos proporo que os
pacotes aumentam de tamanho, quando, mesmo com o mtodo estrito da disciplina prio,
mais pacotes BE concorrem com o trfego de voz. Com o vocoder G.711 (520bytes), por
exemplo, isso mais evidente. quando ento o trfego de fundo enfrenta menos
concorrncia com o nmero de pacotes de voz injetados na rede cada pacote BE, nesse
caso, concorre com menos de 1 pacote prioritrio (apenas 0.68, como mostra a Tabela 5-5
mais adiante, na Sesso 5.2.1).
Disciplina prio (Voz + BE)
0.000
8.000
16.000
24.000
32.000
40.000
48.000
56.000
64.000
72.000
80.000
D
e
l
a
y

(
m
s
)
BE 61.917 44.250 30.500
Voz 8.500 8.583 8.667

Figura 5-6 Delay do trfego de perturbao com a disciplina prio.
bom entender que a modelagem dos vocoders aqui experimentada se baseou
apenas em parmetros possveis de serem caracterizados no testbed, tais como a variao
do tamanho dos pacotes, a variao do nmero de fluxos e a gerao de fluxos formados

62

por uma variao regular de atividade-silncio. Isto quer dizer que atrasos relacionados
gerao/formao dos pacotes de VoIP, prprios do processo de codificao/decodificao
realizado pelos vocoders de udio, foram ignorados nos testes, obviamente porque no
foram empregados vocoders reais, sendo considerados apenas os atrasos de gerao de
dados e de transmisso dos pacotes.
Vale destacar, no entanto, que os atrasos resultantes j incluem a sobrecarga
introduzida por processamentos adicionais da disciplina de escalonamento cbq,
especificamente quanto s atividades de classificao de pacotes, determinao das filas a
serem servidas e clculos de estimativa de banda a ser usada pelas classes do tc.
5.1.2 Estudo do jitter
Os valores de jitter so vistos na Figura 5-7, com o vocoder G.726 marcando,
agora, os valores mais elevados e o G.711 (520bytes) apresentando o melhor resultado.
V-se que o jitter decai com o aumento do tamanho dos pacotes de voz. As
cargas dos trfegos de BE e de EF so sempre proporcionais, com o nmero de fluxos e o
tamanho dos pacotes sendo, praticamente, constantes com BE e variados com EF,
dependendo do vocoder em estudo. Como j abordado, com EF, reduzindo-se o tamanho
dos pacotes, para manter a carga proporcional, deve-se aumentar o nmero de pacotes
injetados na rede
49
. Assim aumenta a probabilidade de que esses pacotes enfrentem maiores
variaes nos atrasos de enfileiramento (queuing delay) ao longo do percurso, sendo mais
possvel que se tenha, mesmo com a atuao estrita da disciplina prio, uma mistura varivel
maior de pacotes de voz com pacotes de melhor esforo.
De uma outra forma, agregados com pacotes de tamanhos maiores apresentam
melhor desempenho quanto ao jitter e isto pode ser explicado pelo comprimento das
rajadas. Ou seja, em disciplina como prio, a presena de rajadas mais longas (pacotes
maiores) reduz o jitter, considerando que os pacotes da mesma rajada experimentam atrasos
de enfileiramento similares. Como conseqncia, tais pacotes atingem tambm valores de
jitters menores[54], conforme se v o comportamento do trfego de voz na Figura 5-7.
Como j explicado, pode-se atribuir ainda os resultados ao fator agregao, que, conforme

63

[49], afeta tambm o jitter mdio experimentado por fluxos prioritrios, que aumenta com a
elevao do nmero de fluxos.
0.000
15.000
30.000
45.000
60.000
75.000
90.000
105.000
120.000
135.000
150.000
165.000
J
i
t
t
e
r

(
m
s
)
BE 129.727 136.167 120.500
Voz 42.417 24.917 21.182

Figura 5-7 Jitter com a disciplina prio.
5.1.3 Estudo das taxas de perdas de pacotes e de vazo
A Figura 5-8 mostra a taxa de descarte de pacotes que os fluxos conseguiram
no estudo experimental, tendo a modelagem do vocoder G.726 obtido o melhor
desempenho e a do G.711, com 520 bytes, apresentando as piores taxas.
Pode-se atribuir tais resultados eficincia com que a disciplina prio consegue
encaminhar um nmero mais evasivo de pacotes menores. Isto motivado pelo fato do
tamanho da fila referente banda prioritria (fila do tipo FIFO, limitada em apenas
1.600bytes) ser fixado em nmero de bytes (BFIFO), o que faz com que pacotes maiores,
mesmo que gerados em menor quantidade, apresentem taxas de descarte mais elevadas,
uma vez que ocupam mais espao da fila. Isto confirmado atravs de testes preliminares,
com filas anexadas s bandas do prio sendo do tipo FIFO e limitada, desta vez, por nmero
de pacotes (PFIFO), em que, nas mesmas condies de rede (carga da rede, n
o
de fluxos,
etc), se percebeu um comportamento contrrio, com taxas de descarte muito baixas e

49
So injetados, em mdia, ao final de cada experimento, 10.351 pacotes na modelagem com G.726, 6.077
pacotes com G.711 (200bytes) e apenas 2.389 pacotes com G.711 (520bytes).

64

tendendo a 0% com o aumento do tamanho dos pacotes
50
. Ou seja, pode-se perceber, neste
caso, que o tamanho dos pacotes no exerceu qualquer influncia na taxa de descarte, uma
vez que o comprimento da fila era inflexvel e limitado por um nmero fixo de pacotes.
Houve uma pequena influncia nas perdas, sim, mas do nmero de pacotes gerados por
segundo, com taxas de descarte maiores para vocoders com taxas de gerao maiores (com
pacotes menores).
0.000
3.000
6.000
9.000
12.000
15.000
18.000
21.000
24.000
T
a
x
a

d
e

P
e
r
d
a

(
%
)
BE 19.536 11.178 5.173
Voz 0.670 1.480 3.603

Figura 5-8 Taxa de descarte de pacotes com a disciplina prio.
Um outro fator que ajuda a explicar o quadro mostrado na Figura 5-8 a
atuao, na banda 0 da disciplina prio, de fluxos de natureza ON-OFF. Ou seja, com uma
agregao maior, momentos de silncio de um fluxo de voz muito provavelmente sero
preenchidos por outros fluxos igualmente prioritrios, com menor possibilidade dos pacotes
de melhor esforo ocuparem a fila da interface de sada. Isto contribui para que trfego com
maior nmero de fluxos apresente melhor desempenho (caso mais bem sucedido a
modelagem do vocoder G.729, com pacotes de apenas 120bytes e distribudos num total de
37 fluxos).
As justificativas acima servem tambm para explicar as taxas de vazo
alcanada (Figura 5-9), uma vez que tem melhor vazo o trfego que encontrou menos
perdas e resistncia durante seu percurso. Como no experimento anterior, v-se, aqui, que a

50
As taxas de descarte dos pacotes de voz com filas PFIFO sendo anexadas disciplina prio foram as
seguintes: 0.6708% para o vocoder G.726, 0.0591% para o vocoder G.711 (200bytes) e 0% para o vocoder
G.711 (520bytes).

65

taxa de vazo alcanada exatamente o reflexo do que ocorre com a taxa de descarte de
pacotes, com a modelagem do G.726 obtendo o melhor desempenho.
76.00%
80.00%
84.00%
88.00%
92.00%
96.00%
100.00%
T
a
x
a

d
e

"
V
a
z
o

A
l
c
a
n
a
d
a
"

(
%
)
Voz 99.46% 98.44% 96.29%
BE 80.60% 88.80% 94.85%

Figura 5-9 Taxa de vazo alcanada, com a disciplina prio.
5.1.4 A disciplina prio num ambiente de sobrecarga
Como j descrito, os resultados de delay entre as modelagens, mostrados na
Figura 5-5, apresentaram, por conta do ambiente controlado e com poucos pontos
geradores de atrasos (roteamento, distanciamento da rede, etc), valores discretamente
diferentes. Buscou-se ento uma forma onde se pudesse visualizar melhor esses valores.
Imaginou-se que, sobrecarregando a rede, isso poderia ocorrer, uma vez que a sobrecarga
fora mais a presena dos mecanismos de qualidade de servio. Optou-se ento em manter
as mesmas configuraes anteriores, reduzindo-se apenas os valores de reserva de banda no
roteador interno em 100%. O cenrio de sobrecarga passou ento a ter a configurao
mostrada na Tabela 5-4.
Os valores experimentados no cenrio de sobrecarga so apresentados na
Figura 5-10 e Figura 5-11, servindo tambm para ratificar os resultados inicialmente
analisados num ambiente menos carregado. Vale comparar a Figura 5-5 e a Figura 5-10(a) e
observar como possvel visualizar, na ltima, uma acentuao maior nos valores de atraso
de voz. A Figura 5-10(b) mostra, em comparao Figura 5-6, o quo o trfego de melhor
esforo se degrada com taxas sobrecarregadas de transmisso.

66

Ambiente de sobrecarga
Tipo de Vocoder
Reserva de banda em QoS5 (Kbps),
atravs da configurao da disciplina cbq
G726-120b 1025.48
G711-200b 1004.00
G711-520b 1021.03
Tabela 5-4 Reservas de banda no roteador interno do domnio DS Cenrio de sobrecarga.

Disciplina prio (Voz) - SOBRECARGA
8.000
9.000
10.000
11.000
12.000
13.000
14.000
15.000
D
e
l
a
y

(
m
s
)
Voz 13.125 13.875 14.750
(a)
Disciplina prio (Voz + BE) - SOBRECARGA
0.000
25.000
50.000
75.000
100.000
125.000
150.000
175.000
200.000
225.000
D
e
l
a
y

(
m
s
)
BE 210.625 184.000 153.500
Voz 13.125 13.875 14.750
(b)
Figura 5-10 Delay com a disciplina prio. Cenrio de sobrecarga.
Confrontada Figura 5-7, a Figura 5-11(a) demonstra valores mais elevados na
variao dos atrasos entre os pacotes (principalmente em relao ao trfego de
background), motivados pela diminuio dos recursos de banda no roteador interno.
J a Figura 5-11(b) e a Figura 5-11(c) mostram como os fluxos prioritrios,
num ambiente de sobrecarga, perdem mais pacotes e, conseqentemente, no conseguem
atingir melhores nveis de vazo, no ultrapassando o limite de 91% (taxa de vazo
alcanada).

67

0.000
50.000
100.000
150.000
200.000
250.000
300.000
350.000
400.000
450.000
500.000
J
i
t
t
e
r

(
m
s
)
BE 331.375 463.125 315.500
Voz 50.500 37.750 23.750

(a)
0.000
10.000
20.000
30.000
40.000
50.000
60.000
70.000
80.000
T
a
x
a

d
e

P
e
r
d
a

(
%
)
BE 74.069 69.093 63.224
Voz 9.389 10.443 19.193

(b)
Disciplina prio(Voz + BE) - SOBRECARGA
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
80.00%
90.00%
100.00%
T
a
x
a

d
e

"
V
a
z
o

A
l
c
a
n
a
d
a
"

(
%
)
Voz 90.60% 89.44% 80.48%
BE 25.80% 30.75% 36.61%
(c)
Figura 5-11 Jitter (a), taxas de perda (b) e de vazo alcanada (c), com prio. Cenrio de
sobrecarga.

5.2 Aplicao da disciplina bfifo
Os atrasos sofridos pelo trfego de voz ganham, com a disciplina bfifo, uma
nova configurao. Ou seja, atingem valores significativamente elevados e so decrescentes
com o aumento do tamanho dos pacotes, tendo a modelagem do vocoder G.711 (520bytes)
apresentado o melhor desempenho. A Figura 5-12(a) ilustra isso, onde as linhas referentes
aos trfegos EF e BE apresentam a mesma tendncia, com os valores de voz sendo
ligeiramente piores que os valores de melhor esforo.
Aqui, ao contrrio da disciplina prio, o trfego de voz no obteve tratamento
diferenciado, o que quer dizer que no foi dada prioridade no escalonamento de seus

68

pacotes, que competiram, de forma direta nas filas de tamanhos fixos
51
, com os pacotes de
melhor esforo. A falta de uma priorizao dos fluxos de voz um fator importante para
justificar a mesma tendncia decrescente das linhas que representam o trfego e,
principalmente, os altos valores de atraso (acima dos 30ms) sofridos pelos agregados de
voz, demonstrados na Figura 5-12(b). Pode-se, nela, comparar os resultados obtidos pela
aplicao das disciplinas prio e bfifo.
Disciplina bfifo (Voz + BE)
0.0000
10.0000
20.0000
30.0000
40.0000
50.0000
60.0000
70.0000
80.0000
D
e
l
a
y

(
m
s
)
Voz 52.625 44.625 33.25
BE 48.625 36.375 28.875
(a)
Voz com as disciplinas prio e bfifo
0.0000
10.0000
20.0000
30.0000
40.0000
50.0000
60.0000
70.0000
80.0000
D
e
l
a
y

(
m
s
)
Voz (bfifo) 52.625 44.625 33.25
Voz (prio) 8.5 8.583333333 8.666666667
(b)
Figura 5-12 (a) Delay com bfifo; (b) Comparao de delays entre as disciplinas prio e bfifo
Alm disso, pode-se explicar o decrescimento dos valores em funo da
concorrncia entre pacotes de voz e BE injetados na rede. A Tabela 5-5 mostra, para cada
tipo de vocoder modelado, o nmero de pacotes de voz e de melhor esforo efetivamente
gerados por segundo e o nmero de pacotes de voz gerados para cada pacote BE. Percebe-
se nessa tabela que o grau de concorrncia de pacotes EF para cada pacote BE diminui com
o aumento do tamanho dos pacotes de voz. Por exemplo, a modelagem do vocoder G.711
(520bytes) a que tem um menor nmero de pacotes de voz concorrendo com cada pacote
de melhor esforo. Este o caso em que gerado o menor nmero de pacotes na rede (voz e
BE), com menos disputa entre eles, o que contribui para que os pacotes caractersticos
desse vocoder cheguem ao n destino num tempo menor em relao aos demais.
A taxa de gerao do trfego de perturbao sempre maior que a dos
agregados de voz. Com isso, lgico imaginar que, sem priorizao de trfego, as filas
sejam mais ocupadas por pacotes BE do que por pacotes de voz, contribuindo para que os
atrasos mdios do trfego de melhor esforo sejam menores do que os de voz.

51
Fila fixa BFIFO gerenciada pelo TC, com comprimento de 16.300bytes, e fila de transmisso da interface
de sada, limitada, por default, em 100 pacotes e com MTU de 1500bytes.

69

Um outro fator que ajuda a caracterizar isto a natureza da fonte de gerao do
trfego. Considerando que os fluxos de voz so ON-OFF (gerados em 20% da banda total
reservada) e que o fluxo de melhor esforo CBR (gerado em 80% da banda total
reservada), os momentos de silncio do trfego de voz so parcial ou inteiramente
preenchidos pelo fluxo BE, o que atrasa os pacotes de voz. A intensidade de tal atraso vai
depender do nmero momentneo de fluxos em estado OFF.
Pacotes gerados na rede

N
o
de pacotes efetivamente
.
Tipo de
Vocoder
Agregado de
Voz
(ON-OFF)
Fluxo BE
(CBR)
N
o
de pacotes EF
gerados para
cada pacote BE
G726-120b 517.55 174.40 2.95
G711-200b 303.85 170.75 1.77
G711-520b 119.45 173.64 0.68
Tabela 5-5 Razo entre pacotes EF e BE gerados na rede.
A Figura 5-13(a) demonstra o grfico da variao mdia do delay, onde se pode
perceber um decrscimo nos valores de voz medida que os pacotes aumentam de
tamanho. Na verdade, voltando aos experimentos com a disciplina prio, v-se, claramente,
uma semelhana nos pontos de jitter entre as disciplinas estudadas vide Figura 5-13(b). A
diferena bsica que, com bfifo, os valores so mais elevados, j que, como explicado
antes, os pacotes modelados de voz no so prioritrios. Logo, competem bem mais com os
pacotes de melhor esforo que com a disciplina prio, o que contribui para uma maior
variao mdia dos atrasos entre os pacotes.
Diante disso, pode-se perfeitamente atribuir os resultados desta sesso s
mesmas justificativas levantadas para a disciplina prio. Ou seja, quanto mais pacotes
injetados na rede (pacotes menores) maior a probabilidade de que esses pacotes sofram
variaes nos atrasos de enfileiramento, com uma miscelnea maior de pacotes de voz com
os de melhor esforo. No se deve esquecer que pacotes maiores, como tm rajadas mais
longas, lidam com atrasos de enfileiramento mais prximos e, por isso, apresentam melhor
desempenho quanto ao jitter.

70

Ademais, h ainda a contribuio da natureza varivel da fonte geradora dos
fluxos de voz (atividade-silncio), que possibilita que o trfego contnuo de fundo preencha
a banda nos momentos de no atuao dos fluxos de voz. Isto permite que, quanto menor o
tamanho dos pacotes de voz, mais pacotes estaro misturados na rede, aumentando o valor
mdio de jitter daqueles pacotes.
Conforme Figura 5-13(a), o jitter de melhor esforo, por sua vez, praticamente
no sofre maiores variaes nos testes, provavelmente porque o trfego BE tenha a mesma
configurao em todos os experimentos.
0.000
15.000
30.000
45.000
60.000
75.000
90.000
105.000
120.000
135.000
150.000
J
i
t
t
e
r

(
m
s
)
BE 110.375 110.75 108.125
Voz 67.25 50.875 49.125
(a)
0.000
15.000
30.000
45.000
60.000
75.000
90.000
105.000
120.000
135.000
150.000
J
i
t
t
e
r

(
m
s
)
Voz (bfifo) 67.25 50.875 49.125
Voz (prio) 42.417 24.917 21.182
(b)
Figura 5-13 (a) Jitter com bfifo; (b) Comparao de jitters entre as disciplinas prio e bfifo
5.2.3 Estudo da taxa de perda de pacotes
Os valores das taxas de descarte de pacotes de voz e de BE (Figura 5-14-a),
assim como no estudo do delay mdio, decrescem com o aumento do tamanho dos pacotes.
Tambm nesta mtrica o vocoder G.711 (520bytes) apresenta o de melhor desempenho
entre as modelagens analisadas na disciplina bfifo. Essa reduo das taxas pode ser
explicada em funo do transbordamento das filas de transmisso de tamanho fixo, mais
evidente medida que os pacotes diminuem de tamanho, quando ento, para garantir a
mesma carga de rede, um maior nmero de pacotes por segundo injetado na rede.
Alm disso, a falta de um disciplinamento prioritrio aos fluxos de voz os
mantm na mesma tendncia decrescente que o trfego de melhor esforo, j que ambos so
tratados indistintamente.

71

Percebe-se ainda na Figura 5-14(a) que as taxas de perdas de voz so, em
comparao s de melhor esforo, consideravelmente mais elevadas, principalmente para o
vocoder G.726, que gera um maior nmero de pacotes. Isso se justifica em funo de dois
fatores, intrinsecamente relacionados: no h tratamento diferenciado entre o tipo de
trfego e a carga de transmisso dos fluxos BE sempre superior dos agregados de voz.
o que faz com que os pacotes de melhor esforo tenham uma maior ocupao das filas e,
conseqentemente, apresentem menores taxas de descarte. Alm disso, os pontos de voz e
de BE mais se aproximam na modelagem G.711 (520bytes), quando ento h menos
pacotes na rede, menor relao de concorrncia pela ocupao das filas e, com isso,
menores taxas de descarte.
A Figura 5-14(b) compara as perdas de voz das disciplinas prio e bfifo, onde se
pode observar comportamentos bastante distintos e discrepncias nos resultados.
0.00
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
P
e
r
d
a

(
%
)
Voz 31.1663 19.2725 6.0988
BE 8.4450 5.4675 3.8163
(a)
0.00
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
P
e
r
d
a

(
%
)
Voz (bfifo) 31.16625 19.2725 6.09875
Voz (prio) 0.670 1.480 3.603
G726-120bytes G711-200bytes G711-520byt es
(b)
Figura 5-14 (a) Taxa de perdas com bfifo; (b) Comparao de taxas de perdas entre as disciplinas
prio e bfifo
Iniciou-se este captulo com um estudo experimental em que disciplinas de
escalonamento foram aplicadas (prio, sfq e pfifo), com o intuito principal de comprovar a
capacidade do ambiente em diferenciar trfego. Tal estudo serviu como pr-requisito para
os prximos experimentos. Aps isso, partiu-se para estudar o desempenho de fluxos
padronizados de distintos vocoders de udio, em ambientes com e sem qualidade de
servio.

72

A aplicao do escalonador prio significou a presena de um ambiente
diferenciado, no qual se percebeu que a modelagem do vocoder G.726, com pacotes de
120bytes, apresentou os menores atrasos e os menores ndices de descarte de pacotes, mas,
no entanto, apresentou as mais altas variaes de atraso entre pacotes. Ou seja, o aumento
do tamanho dos pacotes afetou diretamente no atraso e inversamente no jitter do trfego
modelado de voz. Conclui-se que, com DiffServ no ambiente montado, os melhores
desempenhos foram observados com a modelagem de trfego com pacotes de tamanhos
menores.
De uma outra forma, mantendo-se as mesmas condies de transmisso do
trfego do experimento com prio, aplicou-se no testbed a disciplina de escalonamento do
tipo FIFO (bfifo), que representou a ausncia de qualidade de servio. Observou-se um
comportamento diferente, onde o vocoder G.711, com pacotes de 520bytes, alcanou os
melhores resultados em todas as mtricas de QoS estudadas. Isto , sem diferenciao de
servio, vocoders com pacotes maiores se sobressaem em relao s modelagens com
pacotes menores.

73

6. Estudo da continuidade dos fluxos
Este captulo analisa aspectos relacionados continuidade dos fluxos,
abordando mais precisamente dois estudos: o primeiro investiga o desempenho de tipos de
fontes geradoras distintas e o segundo analisa especificamente o comportamento de
agregados gerados por fontes do tipo atividade-silncio.
6.1 Desempenho de fontes geradoras distintas
Pretende-se, neste estudo, comparar os nveis de eficincia alcanados por
fluxos prioritrios de voz, gerados tanto por origens contnuas (CBR) como por fontes do
tipo atividade-silncio (ON-OFF).
Para os fluxos prioritrios de voz, variou-se o tamanho dos pacotes em 80, 160,
320 e 800 bytes, sendo que, para cada variao desta, foi gerado apenas 01 fluxo de
perturbao, do tipo contnuo (CBR), com pacotes de tamanhos fixos de 1.470 bytes.
Aplicou-se um ambiente de diferenciao, atravs da utilizao da disciplina de servio prio,
com 2 bandas. banda prioritria foi anexada uma fila FIFO de 1.600 bytes, para voz, e
banda de menor prioridade, para acomodar o trfego de fundo, se anexou tambm uma fila
FIFO, mas com 14.700 bytes. Vale ressaltar ainda que todos os fluxos aqui analisados
foram transportados atravs do protocolo UDP.
Da mesma forma que no estudo dos vocoders, como no se controla a
quantidade exata em geraes do tipo ON-OFF, foram usadas nesta anlise taxas de
gerao baseadas em percentagens proporcionais. Ou seja, os fluxos de voz ocupam
sempre 20% da taxa total gerada e o restante preenchido por trfego de perturbao do
meio. Para garantir igualdade entre as variaes, as reservas de banda efetuadas no roteador
interno foram proporcionais s taxas totais geradas (voz + BE). Para o trfego de voz do
tipo CBR, para efeito de comparao com as geraes ON-OFF, utilizou-se o mesmo
raciocnio, injetando-se 20% de voz e 80% de trfego BE.
A Tabela 6-1 apresenta o planejamento do estudo experimental, mostrando,
para cada tamanho de pacote, conforme o princpio proporcional j descrito, as taxas de
gerao e a reserva de banda no roteador interno, assim como a quantidade de fluxos

74

compondo os agregados de voz. Pode-se perceber, a partir da relao entre a vazo total
gerada (voz + BE) e a banda reservada no roteador interno, que o cenrio adotado para este
estudo foi o de sobrecarga, j que foram reservados, em todos os casos, apenas 39.06% de
banda em relao taxa total gerada. Uma melhor visualizao das mtricas de QoS foi o
que motivou a adoo deste cenrio de sobrecarga da rede.

Tipo de
trfego
Tipo de
fonte
Tamanho
dos pacotes
(bytes)
N
o
de fluxos
utilizados
Vazo efetiva
em cada fluxo
(Kbps)
Vazo total
efetiva por
trfego
(Kbps)
Reserva de
banda no
roteador
interno
cbq/prio
(Kbps)
Voz ON-OFF 80 19 26.40 501.60
1.1
BE CBR 1470 1 2006 2006
979.53

Voz CBR 80 8 64.00 512
1) 80
bytes
1.2
BE CBR 1470 1 2048 2048
1000

Voz ON-OFF 160 19 26.40 502.00
2.1
BE CBR 1470 1 2008 2008
980.47

Voz CBR 160 8 64.00 512
2) 160
bytes
2.2
BE CBR 1470 1 2048 2048
1000

Voz ON-OFF 320 19 26.40 502.46
3.1
BE CBR 1470 1 2009 2009
981.04

Voz CBR 320 8 64.00 512
3) 320
bytes
3.2
BE CBR 1470 1 2048 2048
1000

Voz ON-OFF 800 19 26.53 503.90
4.1
BE CBR 1470 1 2015 2015
983.95

Voz CBR 800 8 64.00 512
4) 800
bytes
4.2
BE CBR 1470 1 2048 2048
1000
Tabela 6-1 Planejamento do estudo
importante lembrar ainda que, para os fluxos do tipo ON-OFF, em cada
segundo de teste, 400ms foram utilizados para gerao de pacotes e o restante (600ms) foi
de silncio.
A Figura 6-1 apresenta os atrasos mdios em uma direo dos agregados de
voz, gerados por fontes ON-OFF e CBR, em tamanhos de pacotes variados. So

75

percebidos, de uma maneira geral, dois fatores importantes: o primeiro que fluxos de voz
com origem atividade-silncio sofrem mais atrasos que os gerados por fontes contnuas e o
segundo que o tamanho dos pacotes de voz, em sua essncia, influencia nos resultados.
Estudo da continuidade dos fluxos prioritrios
11.500
12.000
12.500
13.000
13.500
14.000
14.500
15.000
15.500
16.000
D
e
l
a
y

V
o
z

(
m
s
)
Fluxos On-Off 13.250 12.000 13.750 15.625
Fluxos CBR 12.125 11.875 13.250 15.500
80bytes 160bytes 320bytes 800bytes

Figura 6-1 Delay mdio dos fluxos de voz.
Como j se sabe, o escalonador utilizado no roteador interno o de
enfileiramento com prioridade estrita, tendo os fluxos de voz maior preferncia do que o
fluxo de melhor esforo. Na verdade, isso quer dizer que os pacotes de fundo so servidos
apenas quando a fila mais prioritria estiver ociosa. No entanto, pacotes de voz chegando
em fila vazia devem aguardar o encaminhamento de pacote de fundo, se houver, e isso
contribui para a elevao do atraso mdio dos pacotes EF. Percebe-se ento que, de
qualquer forma, h uma certa afluncia entre os fluxos. Tendo-se trfego de voz com
origem ON-OFF, os pacotes BE apresentam mais chances de estar ocupando a fila de
transmisso, uma vez que pacotes EF no so continuamente injetados na rede. Isso
contribui para uma concorrncia maior entre os pacotes e, conseqentemente, para a
ocorrncia de atrasos mdios mais elevados com trfego de voz do tipo atividade-silncio
do que com trfego de voz com origem CBR.
Agora, com relao atuao dos pacotes de melhor esforo, estes, conforme
se pode perceber na Figura 6-2, quando associados ao trfego EF do tipo ON-OFF,
apresentam menores atrasos do que quando injetados juntamente com fluxos contnuos de
voz. a comprovao de que, na companhia de fluxos prioritrios de origem atividade-

76

silncio, h uma maior ocupao de pacotes BE na rede, prejudicando a atuao do trfego
prioritrio de voz
52
. Na verdade, os altos valores mdios de atrasos dos pacotes maiores de
voz refletem positivamente nos atrasos dos fluxos de fundo, que, no importando a fonte de
gerao EF, decrescem com o aumento do tamanho dos pacotes de voz.
Estudo da continuidade dos fluxos prioritrios -
Atuao do trfego de fundo
150.000
165.000
180.000
195.000
210.000
225.000
240.000
255.000
270.000
285.000
300.000
D
e
l
a
y

B
E

(
m
s
)
Fluxos On-Off 254.00 206.63 178.88 157.00
Fluxos CBR 279.38 215.00 188.13 160.00

Figura 6-2 Delay mdio do trfego de fundo (BE).
Nota-se tambm na Figura 6-1 que o tamanho dos pacotes influencia
diretamente no desempenho do agregado de voz. Assim como no estudo dos vocoders
(Captulo 5), quanto maior o tamanho dos pacotes, mais tempo ser gasto para se gerar e,
conseqentemente, para se transmitir esses pacotes na rede, contribuindo assim para a
ocorrncia de atrasos maiores, independentemente do tipo da fonte geradora dos fluxos.
Com base no mesmo raciocnio da Tabela 5-3, isso demonstrado na Tabela 6-2 e na
Tabela 6-3, que, a partir do nmero de pacotes efetivamente gerados por segundo
53
,
apresenta os tempos necessrios para a gerao dos pacotes, os quais, como se pode ver
nas colunas referentes aos pacotes EF (com CBR e com ON-OFF), crescem com o aumento
do tamanho dos pacotes.

52
Alm dos atrasos, o trfego BE, quando injetado juntamente com o agregado de voz do tipo ON-OFF,
apresentou taxas de descarte menores que com os agregados CBR, ajudando a comprovar a maior ocupao
de pacotes de fundo quando injetados com fluxos de voz atividade-silncio.
53
Pode-se, teoricamente, calcular o nmero de pacotes por segundo gerados na rede. No entanto, na prtica,
os nmeros de pacotes gerados podem, por ineficincia da ferramenta, no coincidir exatamente com os
valores calculados. O termo efetivamente gerados significa o registro da quantidade de pacotes gerados
em laboratrio e, no, valores tericos.

77

Percebe-se ainda na Figura 6-1 que, com pacotes de voz com tamanhos de 80
bytes, os atrasos sofrem uma certa elevao. Isto pode ter sido uma conseqncia das
significativas taxas de descarte de pacotes de 80 bytes (ver Figura 6-4), os quais foram
gerados, para manter a mesma carga, em maior quantidade do que com os demais
tamanhos.
Fluxos de voz do tipo ON-OFF


Tamanho de
pacote (bytes)
Agregado de Voz
ON-OFF
Fluxo BE (CBR) Tempo para
gerar 1
pacote EF
(ms)
Tempo para
gerar 1 pacote
BE (ms)
80bytes 763.01 170.58 1.311 5.862
160bytes 379.37 170.75 2.636 5.857
320bytes 189.35 170.92 5.281 5.851
800bytes 74.53 171.33 13.417 5.837
Tabela 6-2 Clculo de tempo para gerao de pacotes, com agregado de voz do tipo ON-OFF

Fluxos de voz do tipo CBR


Tamanho de
pacote (bytes)
Agregado de Voz
CBR
Fluxo BE (CBR) Tempo para
gerar 1
pacote EF
(ms)
Tempo para
gerar 1 pacote
BE (ms)
80bytes 800.00 174.17 1.250 5.742
160bytes 400.00 174.17 2.500 5.742
320bytes 200.00 174.17 5.000 5.742
800bytes 75.89 174.17 13.177 5.742
Tabela 6-3 Clculo de tempo para gerao de pacotes, com agregado de voz do tipo CBR
A variao mdia do atraso entre pacotes mostrada na Figura 6-3. Observa-se
que as curvas so decrescentes com o aumento do tamanho dos pacotes e que h uma
significante diferena nos valores, tendo os fluxos de voz do tipo CBR alcanado os mais
elevados nveis de jitter.
As mesmas explicaes encontradas para justificar o decrescimento do valor de
jitter no estudo dos vocoders sero utilizadas aqui neste estudo, j que se tratam de cenrios

78

semelhantes, no sentido de que se varia o tamanho dos pacotes de voz e se deixa o fluxo de
perturbao inalterado em todos os experimentos. Na verdade, dois fatores justificam as
curvas decrescentes do jitter: o primeiro que, com pacotes menores, vai se tendo mais
pacotes na rede e, com isso, aumenta a probabilidade de se ter uma mistura varivel maior
de pacotes de voz e de melhor esforo na fila de transmisso; o segundo fator fica por conta
de que, com pacotes maiores, as rajadas so mais longas e os atrasos de enfileiramento so
mais parecidos, contribuindo para que os jitters sejam menores.
25.000
30.000
35.000
40.000
45.000
50.000
55.000
60.000
65.000
J
i
t
t
e
r

V
o
z

(
m
s
)
Fluxos CBR 62.625 58.250 55.375 43.125
Fluxos On-Off 36.250 31.250 31.125 26.857

Figura 6-3 Jitter mdio do trfego de voz.
Conforme a Figura 6-3, os valores de jitter relacionados aos fluxos de origem
CBR so, para qualquer tamanho de pacote, maiores que os gerados por fontes ON-OFF.
Da Figura 6-4, pode-se observar perfeitamente que os pacotes de voz do tipo CBR
alcanaram taxas mdias de perda razoavelmente menos elevadas que os pacotes de voz do
tipo atividade-silncio. Pode-se afirmar com isso que foram encaminhados bem mais
pacotes de voz CBR do que ON-OFF (ver Tabela 6-4
54
). Ou seja, como a carga de trfego
de fundo praticamente a mesma em ambos os casos (ver coluna Fluxo BE na Tabela 6-2
e na Tabela 6-3), foram tratados mais pacotes na rede com trfego CBR do que com
agregado ON-OFF. Conclui-se assim que h uma maior mistura varivel entre pacotes EF e
de fundo com fluxos de voz do tipo contnuo, sendo, esta, a causa dos valores de jitter com
trfego de voz do tipo CBR serem mais elevados.

54
Pacotes encaminhados na rede so, obviamente, todos os que no foram descartados. Logo, podem ser
calculados a partir das taxas de perda de pacotes da Figura 6-4 (= 100% taxa de descarte).

79

Taxa de pacotes de voz
encaminhados na rede (%)
Tipo de fonte de voz
Tamanho do pacote ON-OFF CBR
80bytes 86.82 94.96
160bytes 93.23 99.41
320bytes 90.21 97.92
800bytes 81.94 88.82
Tabela 6-4 Percentuais de pacotes CBR e ON-OFF encaminhados na rede.
6.1.3 Estudo da taxa de perda de pacotes
0.000
2.000
4.000
6.000
8.000
10.000
12.000
14.000
16.000
18.000
20.000
P
e
r
d
a

V
o
z

(
%
)
Fluxos On-Off 13.178 6.768 9.795 18.065
Fluxos CBR 5.043 0.586 2.080 11.181

Figura 6-4 Taxa mdia de descarte de pacotes do trfego de voz.
Pacotes de voz do tipo ON-OFF foram os mais descartados, conforme Figura
6-4, muito possivelmente devido natureza das geraes dos pacotes. Como j se sabe,
com o princpio estrito da disciplina prio, pacotes de fundo sero servidos apenas nos
momentos de ociosidade da fila mais prioritria. Fluxos de voz gerados por fontes
atividade-silncio, mesmo que em forma de agregao, do mais possibilidade dos pacotes
BE preencherem a fila de transmisso do que fluxos CBR, porque estes, por no sofrerem
interrupes momentneas, estaro sempre sendo encaminhados pela disciplina e ocuparo
mais constantemente a fila de transmisso.

80

6.2 Agregao ON-OFF de fluxos prioritrios
Este um estudo particular, que analisa especificamente, num ambiente com
DiffServ, o desempenho de fluxos agregados, gerados por fontes do tipo atividade-silncio.
Para isso, foram comparados, na ausncia de pacotes de melhor esforo, trfegos
equivalentes com agregao e sem agregao (com apenas 01 fluxo). A disciplina de servio
aplicada foi a prio, sendo utilizada apenas a banda 0, com uma fila FIFO de 1.600 bytes, j
que fluxos de perturbao no foram gerados. O protocolo de transporte adotado nos
experimentos foi o UDP.
Tal como no estudo anterior, os pacotes sofreram alterao de tamanho (80,
160, 320 e 800 bytes) e, para manter a igualdade entre as variaes
55
, as cargas injetadas
foram equivalentes entre os cenrios com e sem agregao, conforme mostra a Tabela 6-5,
que apresenta tambm, para comprovar tal correspondncia, o nmero de pacotes gerados
na rede. Para possveis comparaes futuras, as reservas de banda utilizadas aqui seguiram
os mesmos valores do estudo da continuidade dos fluxos. Como no h concorrncia com
trfego BE, os valores reservados no roteador interno so suficientemente grandes para a
passagem dos fluxos estudados, os quais percorrem os ns da rede sem maiores
resistncias.
As Figura 6-5 e a Figura 6-6 apresentam, respectivamente, os valores mdios de
delay e jitter para cada tipo de trfego, onde se pode perceber claramente o melhor
desempenho dos fluxos agregados em relao ao trfego sem agregao. As taxas mdias
de descarte de pacotes, mostradas na Figura 6-7, tambm confirmam isso. Pode-se atribuir
os resultados ao fundamento bsico do modelo DiffServ, em que microfluxos constituem
um trfego agregado maior, para o qual as reservas de recursos so alocadas, com este
conjunto inteiro de fluxos recebendo um tratamento diferenciado.

55
Entre os tipos de trfego (com e sem agregao) e entre os tamanhos dos pacotes.

81

Tipo de
trfego
N
o
de
fluxos
Taxa de pacotes
efetivamente
gerados por
segundo
N
o
total de
pacotes
gerados na
rede
56

Reserva de
banda no
roteador
interno
cbq/prio
(Kbps)
Agregado 19 40 15.162
1) 80 bytes
1 Fluxo 1 760 15.200
979.53

Agregado 19 20 7.600
2) 160 bytes
1 Fluxo 1 380 7.600
980.47

Agregado 19 10 3.800
3) 320 bytes
1 Fluxo 1 190 3.800
981.04

Agregado 19 4 1.520
4) 800 bytes
1 Fluxo 1 76 1.520
983.95
Tabela 6-5 Estudo da agregao ON-OFF Planejamento.
Estudo da agregao com fluxos ON-OFF
0.000
2.000
4.000
6.000
8.000
10.000
12.000
14.000
16.000
18.000
20.000
D
e
l
a
y

(
m
s
)
On-Off - 1 Fluxo 13.000 10.500 9.375 6.375
On-Off - Agregado 8.000 4.375 3.500 4.125

Figura 6-5 Estudo da agregao com fluxos ON-OFF Valores mdios de delay.

56
Valor mdio, calculado a partir das repeties.

82

0.000
5.000
10.000
15.000
20.000
25.000
30.000
J
i
t
t
e
r

(
m
s
)
On-Off - 1 Fluxo 21.000 20.625 21.625 17.500
On-Off - Agregado 17.000 10.750 3.625 3.125

Figura 6-6 Estudo da agregao com fluxos ON-OFF Valores mdios de jitter.
0.000
5.000
10.000
15.000
20.000
25.000
30.000
35.000
40.000
45.000
50.000
P
e
r
d
a

(
%
)
On-Off - 1 Fluxo 41.441 24.705 12.245 1.046
On-Off - Agregado 10.686 0.540 0.000 0.000

Figura 6-7 Estudo da agregao com fluxos ON-OFF Taxas mdias de perda de pacotes.
Na verdade, chama a ateno os altos percentuais de pacotes descartados em 1
fluxo, o que acaba refletindo nas demais mtricas. Ou seja, sem agregao, quanto maior a
taxa de gerao de pacotes (ver Tabela 6-5), significativamente maior a quantidade de
pacotes perdidos (Figura 6-6, On-Off - 1 fluxo). Com 1 fluxo de 80 bytes, por exemplo,
so gerados efetivamente na rede 760 pacotes em cada segundo e a taxa de descarte de
41.4%. J com pacotes de 800 bytes (ainda com relao ao trfego de 1 fluxo), so gerados

83

efetivamente apenas 76 pacotes num segundo, sendo a taxa de descarte prxima de zero e
pouco pior do que a atingida com agregao.
Do outro lado, com fluxos agregados, pode-se perceber as baixas taxas de
descarte de pacote e, conseqentemente, melhores desempenhos de delay e de jitter. Ocorre
que, com trfego agregado do tipo ON-OFF, cada fluxo que compe esse trfego gera
poucos pacotes por segundo e os momentos de inatividade de alguns fluxos certamente so
preenchidos por outros que estejam no estado ON. Desta forma, h uma saturao muito
menor da fila FIFO (anexada disciplina prio) com agregado de fluxos do que com trfego
de apenas 1 fluxo, o qual, ao contrrio da agregao: gera rajadas bem maiores
57
nos
momentos de atividade em cada segundo, no utiliza os momentos OFF de cada segundo
(600ms) e, como conseqncia, sobrecarrega as filas do tc e de transmisso, causando
maior degradao no desempenho. importante lembrar que isto mais evidente medida
que as taxas de gerao aumentam (pacotes menores), no importando se o trfego
agregado ou no.
Estudou-se inicialmente, neste captulo, o comportamento de fluxos gerados
por fontes contnuas e ON-OFF, numa rede com priorizao de trfego.
Variou-se o tamanho dos pacotes prioritrios e se pde perceber quanto isso
influenciou diretamente no desempenho desses pacotes, com reflexos nas mtricas de QoS.
O aumento do tamanho dos pacotes significou, basicamente, a degradao do atraso dos
fluxos de voz e a melhora dos valores de jitters desses fluxos. Nessas mtricas, o trfego
ON-OFF apresentou, para todos os tamanhos de pacotes, melhor desempenho do que os
fluxos contnuos (CBR).
Aplicou-se tambm um estudo especfico para analisar, sem perturbao do
meio, o fator agregao em fluxos do tipo atividade-silncio. Observou-se que trfego
agregado (composto por 19 fluxos) alcanou, em todas as mtricas e em pacotes de todos
os tamanhos (80, 160, 320 e 800bytes), melhor desempenho que trfego com apenas 1
fluxo.

57
No exemplo estudado, trfego com 1 fluxo gera rajadas 19 vezes maiores que o trfego agregado.

84

7. Impactos do trfego de fundo
Estudam-se, neste captulo, os efeitos da variao do trfego de melhor esforo
no trfego modelado de voz. Para isso, caracterizou-se, em todos os experimentos, o
vocoder G.711 com frame size de 60ms e correspondentes pacotes com 520bytes de
tamanho. Utilizou-se a disciplina prio para o escalonamento dos pacotes.
Este estudo experimental compreendeu a implementao de duas etapas. A
primeira teve a finalidade de analisar a implicao, no desempenho do trfego de voz, de
fluxos de melhor esforo com protocolos de transporte e tamanhos de pacotes distintos. A
fase foi complementada, para fins de comparao, com a observao do desempenho do
trfego de voz sem perturbao do ambiente. A segunda etapa do estudo teve o objetivo de
avaliar os efeitos no desempenho de fluxos de voz causados pela injeo na rede de trfego
de melhor esforo do tipo FTP.
7.1 Primeira etapa
Foram aplicados, como trfego de fundo, fluxos dos tipos UDP e TCP, sendo
que, para cada um deles, variou-se o tamanho dos pacotes BE em 256, 512 e 1500bytes.
Reservou-se, em todos os casos, a banda de 1500Kbps no roteador interno da rede (QoS5).
80% do trfego total gerado na rede foi do tipo melhor esforo e, o restante, destinado aos
agregados de voz, conforme se pode observar na Tabela 7-1:
Na verdade, o objetivo aqui foi comparar a influncia dos protocolos de
transporte com a rede, experimentando, em cada tipo de protocolo, as mesmas condies
de carga. Ou seja, planejou-se inicialmente o estudo com o protocolo TCP (sem qualquer
outro trfego) e, depois, foram aplicadas exatamente as mesmas condies com o protocolo
UDP. Na Tabela 7-1, as taxas geradas no trfego de melhor esforo so distintas, dada a
natureza cooperante ou adaptativa do protocolo TCP, onde no se tem controle sobre a
vazo resultante, a qual depende do estado momentneo da rede. As vazes BE
conseguidas foram as que mais se aproximaram da reserva de banda fixada no roteador

85

interno do testbed, que foi 1.500Kbps. Tambm por causa da natureza do protocolo TCP
que este valor permaneceu constante para todos os tamanhos de pacotes BE
58
.
Tamanho
dos pacotes
BE
(payload)
BE Voz Taxa total
gerada na
rede
Reserva de banda em QoS5
(Kbps), atravs da
configurao da disciplina
cbq
Taxa gerada
(Kbps)
1334.61
333.65
(11 fluxos)
1668.26 256bytes

% 80.00% 20.00% 100%
1500.00
Taxa gerada
(Kbps)
1560.58
390.14
(13 fluxos)
1950.72 512bytes

% 80.00% 20.00% 100%
1500.00
Taxa gerada
(Kbps)
1620.00
420.40
(14 fluxos)
2040.40 1500bytes

% 79.40% 20.60% 100%
1500.00
Tabela 7-1 Planejamento da 1
a
etapa Taxas de gerao usadas nos protocolos TCP e UDP em BE e
em Voz
Para a gerao dos 20% restantes de trfego da rede, equivalente aos agregados
de voz caracterizados como o G.711 (520bytes), foram necessrios 11, 13 e 14 fluxos,
respectivamente utilizados nos testes com pacotes BE de 256, 512 e 1500bytes. Ainda com
relao ao trfego de voz, importante frisar que o protocolo de transporte empregado foi
o UDP e que a fonte de gerao utilizada foi do tipo ON-OFF.
A ferramenta de gerao/medio do trfego TCP utilizada nos testes foi, como
j descrito anteriormente, o NETPERF, responsvel em calcular a vazo resultante
(desempenho) do fluxo em estudo, a partir da medio do nmero de transaes TCP
(request/response)
59
. importante saber que cada transao contabilizada assim que o n
de origem receber, do n de destino, um pacote de confirmao (acknowledge ou ACK),
em resposta transmisso de um pacote. Os pacotes de transmisso tiveram seus tamanhos
variados (256, 512 ou 1500bytes), mas os pacotes de confirmao foram fixados num
menor tamanho possvel (1 byte), haja vista ter-se o mnimo de impacto na comparao com
o trfego UDP, que no tem confirmaes.

58
Alterando-se o valor de reserva, automaticamente a vazo TCP resultante se adapta em novos valores.
59
Uma transao TCP definida como a troca de uma nica solicitao (request) e uma nica resposta
(response)[52] Teste de desempenho do Netperf do tipo TCP_RR.

86

Observou-se, inicialmente, o desempenho no atraso dos agregados de voz sem a
interferncia de qualquer outro trfego na rede. Injetou-se, ento, de forma isolada, as
mesmas cargas de fluxos de voz que a gerada, posteriormente, com o trfego de fundo. Isto
, foram introduzidos, a princpio, apenas os agregados de voz, compostos por 11, 13 e 14
fluxos, e, diante disso, verificou-se o atraso mdio de cada um deles. Pode-se visualizar, na
Figura 7-1, que os valores alcanados foram pequenos e os mesmos em cada caso (4ms), j
que, em nenhum dos experimentos, se gerou mais do que 29% da banda reservada no
roteador interno (1.500Kbps).
Passou-se ento a analisar o quo o trfego de fundo exerce influncia no
desempenho dos mesmos agregados de voz observados inicialmente de forma isolada. A
Figura 7-1 apresenta os resultados dos atrasos mdios, diante da variao do tipo de
protocolo de transporte e do tamanho dos pacotes do trfego de melhor esforo.
Impacto do trfego de fundo no desempenho dos agregados de voz
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
D
e
l
a
y

V
o
z

(
m
s
)
BE UDP 7.583 8.750 9.250
BE TCP 5.333 6.500 7.750
Voz sem BE 4.000 4.000 4.000
BE-256bytes BE-512bytes BE-1500bytes

Figura 7-1 Impacto do trfego BE Valores mdios de delay de voz.
Diante da elevao dos valores, pode-se perceber, claramente, como o trfego
de melhor esforo exerce uma significativa influncia no desempenho dos fluxos prioritrios
de voz. V-se, ainda, que os atrasos so crescentes com o tamanho dos pacotes BE e que a
gerao de trfego de fundo com protocolo UDP degrada mais a atuao dos fluxos EF que
com o protocolo TCP.

87

Pacotes de fundo, apesar de menos prioritrios, so transmitidos na rede
juntamente com o trfego de voz. Na verdade, exercem influncia porque os fluxos
prioritrios tm origem ON-OFF e, nos momentos de menor atividade, a banda
preenchida por pacotes oportunistas do tipo BE. Quanto maior forem esses pacotes de
fundo, conseqentemente mais tempo levaro os pacotes de voz, a eles misturados, a
atravessarem a rede at a mquina de destino, o que resulta na tendncia crescente das
linhas (BE UDP e BE TCP).
Justifica-se uma menor influncia do trfego TCP em funo da prpria
natureza desse protocolo, uma vez que o mesmo consegue ajustar-se, atravs de
retransmisses e de acordo com o grau de ocorrncia de descartes de pacotes, sua taxa de
gerao, causando menos congestionamentos na rede e fazendo com que os pacotes EF
permaneam menos tempo nas filas. De uma outra forma, o protocolo UDP, sem esquema
de retransmisses e adaptao ao meio, gera os pacotes a uma taxa constante de bits, sem
se preocupar com congestionamentos, causando maiores atrasos nos fluxos prioritrios de
voz.
importante lembrar ainda que, com pacotes BE com carga til de 1500 bytes,
como so transmitidos mais bytes do que a rede ethernet pode transmitir numa unidade de
transmisso (MTU de 1500bytes, para payload e cabealhos), ocorre fragmentao dos
pacotes e, com isso, se enfrenta mais congestionamento de rede. Esse fator registrado na
Figura 7-1, onde o atraso mdio de fluxos de voz, com BE de 1500 bytes, alcana os mais
altos valores. Isso vai ser refletido tambm nas demais mtricas.
A variao dos atrasos entre pacotes pode ser observada na Figura 7-2, em que
se percebe tambm como o trfego de fundo influencia no comportamento dos fluxos
prioritrios. Tal como no estudo do delay, os valores so crescentes com o aumento do
tamanho dos pacotes BE e a linha referente ao protocolo UDP se posiciona sempre acima
da que representa o protocolo TCP, sendo que, em BE com os tamanhos de 256 e
512bytes, essa diferena muito discreta. No entanto, chama a ateno o aumento
desproporcional no valor do jitter quando se injetam pacotes de fundo com tamanhos de
1500bytes, tanto com o protocolo UDP quanto com TCP, registrando assim como a

88

fragmentao de quadros ethernet pode degradar (mais no sentido de variao dos atrasos)
a qualidade de servio de fluxos de tempo real.
Nas mesmas condies, em que h fragmentao de quadros ethernet, e numa
rede mais extensa geograficamente, com mais pontos de roteamento, maior nmero de filas
e links de baixa velocidade, esses valores tenderiam a se propagar, chegando, talvez, a
valores inviveis para a execuo de aplicaes VoIP, o que foco de investigao em
testbeds com outras topologias.
Impacto do trfego de fundo no desempenho dos agregados de voz
0.000
2.000
4.000
6.000
8.000
10.000
12.000
14.000
16.000
18.000
20.000
J
i
t
t
e
r

V
o
z

(
m
s
)
BE UDP 6.000 7.000 17.250
BE TCP 5.500 6.750 11.333
Voz sem BE 3.125 3.714 3.500

Figura 7-2 Impacto do trfego BE Valores mdios de jitter de voz.
Pode-se observar ainda no grfico que, com a ausncia de trfego de fundo,
praticamente no h variao nos valores de jitter de voz com o aumento do nmero de
fluxos EF, j que, alm de terem banda extra disposio, os pacotes no encontram
concorrncia com outros trfegos.
Nos estudos anteriores (com a disciplina prio), manteve-se o tamanho dos
pacotes de fundo constante, variou-se apenas o tamanho dos pacotes de voz e percebeu-se
que, quanto maior eram os pacotes de voz menor era o valor de jitter mdio. A linha do
grfico foi decrescente e, como se deve lembrar, se atribuiu isso ao nmero de pacotes
prioritrios injetados na rede em relao ao tamanho desses pacotes e ao comprimento das
rajadas. Neste experimento, de uma outra forma, mesmo que em condies de carga
distintas, mantendo-se o tamanho dos pacotes prioritrios e variando-se agora o tamanho
dos pacotes BE, encontrou-se um crescimento no valor mdio do jitter de voz. Aqui, a

89

causa que, quanto maior o tamanho dos pacotes de perturbao, mais variaes de atrasos
nas filas (fila FIFO do prio, gerenciada pelo tc, e fila de transmisso da interface) os pacotes
prioritrios de voz iro sofrer. De qualquer forma, da mesma maneira que em [49], pode-se
concluir sucintamente que o jitter mdio ento uma funo tanto do tamanho dos pacotes
EF quanto do tamanho dos pacotes de fundo.
7.1.3 Estudo das taxas de perda de pacotes e de vazo
A Figura 7-3 e a Figura 7-4 demonstram, respectivamente, as taxas de
descarte e de vazo alcanada para este experimento. So comprovadas as tendncias
de desempenho discutidas nas mtricas anteriores, com as taxas sofrendo maior degradao
com o aumento do tamanho dos pacotes de fundo e com o trfego de melhor esforo com
UDP exercendo maior impacto nos fluxos de voz do que o trfego do tipo TCP. Alm
disso, v-se, mais uma vez, a inverso na tendncia dos valores entre essas mtricas.
Impacto do trfego de fundo no desempenho dos agregados de
voz
0.000
0.500
1.000
1.500
2.000
2.500
3.000
3.500
4.000
4.500
5.000
P
e
r
d
a

V
o
z

(
%
)
BE UDP 0.211 3.204 3.369
BE TCP 0.000 2.157 2.686
Voz sem BE 0.000 0.000 0.000

Figura 7-3 Impacto do trfego BE Valores mdios de perda de pacotes prioritrios.
Quanto s perdas, pode-se observar na Tabela 7-1 que, assim como o nmero
de fluxos prioritrios, as taxas de gerao dos trfegos de voz e de fundo aumentam com o
tamanho dos pacotes BE, mas, no entanto, a reserva efetuada no roteador interno
permanece inalterada em todo o estudo (em 1500Kbps). Com isto, medida que se
aumenta a taxa total de vazo (EF + BE) da rede e conserva-se a reserva de banda no

90

interior do domnio, maior tende a ser o nmero de pacotes prioritrios descartados,
independentemente do tipo de protocolo de transporte utilizado no trfego BE.
Impacto do trfego de fundo no desempenho dos
agregados de voz
95.000%
95.500%
96.000%
96.500%
97.000%
97.500%
98.000%
98.500%
99.000%
99.500%
100.000%
"
V
a
z
o

A
l
c
a
n
a
d
a
"

-

V
o
z

(
%
)
BE UDP 99.707% 96.774% 96.376%
BE TCP 99.758% 97.821% 97.387%
Voz sem BE 100.00% 100.00% 100.00%

Figura 7-4 Impacto do trfego BE Taxas mdias de vazo alcanada de pacotes prioritrios.
Da mesma forma, quanto mais pacotes de voz injetados, maior deve ser a
atuao da disciplina prio em dar preferncia a esses pacotes. Como conseqncia, maior
a degradao do fluxo de melhor esforo com fontes UDP, por este ser contnuo e no
cooperante. A Figura 7-5(a) mostra esta tendncia e a Figura 7-5(b) apresenta a taxa de
vazo alcanada dos fluxos de perturbao injetados neste estudo. O trfego de fundo do
tipo TCP, dada sua natureza adaptativa, no apresentou pacotes descartados.
Trfego de Fundo
0.000
5.000
10.000
15.000
20.000
25.000
30.000
P
e
r
d
a

B
E

(
%
)
UDP 13.153 18.034 26.328
TCP 0.000 0.000 0.000
(a)
Trfego de Fundo
70.000%
75.000%
80.000%
85.000%
90.000%
95.000%
100.000%
V
a
z
o

A
l
c
a
n
a
d
a

-

B
E

(
%
)
UDP 86.804% 81.930% 73.668%
TCP 80.877% 77.838% 76.609%
(b)
Figura 7-5 Trfego BE (a) Taxa de perda de pacotes; (b) Taxa de vazo alcanada.
Vale observar que a taxa de vazo alcanada para o trfego BE/UDP (Figura
7-5-b) exatamente a inverso dos valores relativos taxa de perdas para o mesmo trfego

91

(Figura 7-5-a). No entanto, no foi o caso com os fluxos TCP, que apresentaram 0% de
taxa de descarte (em todos os tamanhos) e deveriam alcanar, pelo mesmo raciocnio
tomado com UDP, 100% de taxa de vazo alcanada. Isto no aconteceu devido ao
controle de transmisso do protocolo, que permanentemente oscila a taxa de bits gerados,
para que pacotes nunca sejam perdidos.
7.1.4 Estudo da agregao de voz (uso de apenas 1 fluxo prioritrio)
Faz-se, nesta sesso, uma anlise comparativa dos resultados apresentados nos
itens anteriores deste captulo, em que foi utilizado trfego agregado de voz. Aqui, ao
contrrio, monta-se um cenrio marcado por apenas 1 fluxo prioritrio de voz. So, na
verdade, casos extremos. Ou seja, no primeiro momento se usou, dependendo do tamanho
do pacote de fundo, 11, 13 ou 14 fluxos EF. No segundo caso, reproduzindo-se as mesmas
condies de carga do trfego agregado de voz (n de pacotes gerados e vazo), se aplicou
apenas 01 fluxo EF. Isto , a configurao do trfego de voz utilizada nesta sesso, em
termos de tamanho dos pacotes
60
, carga do trfego de fundo e reserva de banda no roteador
interno, foi a mesma aplicada com as agregaes.
Os grficos repetem as linhas referentes aos agregados de voz, utilizando os
protocolos UDP e TCP, e incluem os valores relativos ao trfego com 1 fluxo prioritrio,
tambm com os mesmos protocolos de transporte. A Figura 7-6 mostra, para cada caso e
com base nessas informaes, os valores mdios de delay. Pode-se observar nessa figura
que os agregados de voz, da mesma forma que no estudo da agregao ON-OFF de fluxos
prioritrios (Sesso 6.2), obtiveram melhores desempenhos que o trfego com fluxos
nicos, independentemente do tipo de protocolo de transporte. Isto se repete para os
valores de jitter (Figura 7-7) e justificado em decorrncia dos fluxos agregados do tipo
ON-OFF gerarem, cada um deles, poucos pacotes por segundo, com uns fluxos
preenchendo as filas nos momentos de inatividade (OFF) dos outros. Assim sendo, essas
filas so muito menos saturadas do que o trfego com apenas 1 fluxo ON-OFF, o qual, por
sua vez, gera rajadas maiores no estado de atividade e, conseqentemente, tem seu
desempenho mais degradado.

60
Caracterizao do vocoder G.711, com frame size de 65ms e correspondentes pacotes com tamanhos de
520bytes.

92

Impacto do trfego de fundo - Estudo da agregao de voz
4.000
5.000
6.000
7.000
8.000
9.000
10.000
D
e
l
a
y

V
o
z

(
m
s
)
1 Fluxo- BE UDP 7.750 9.083 9.667
Agregado- BE UDP 7.583 8.750 9.250
1 Fluxo- BE TCP 5.667 7.417 8.500
Agregado- BE TCP 5.333 6.500 7.750

Figura 7-6 Impacto do trfego de fundo (estudo da agregao de voz) - Valores mdios de delay.

4.000
6.000
8.000
10.000
12.000
14.000
16.000
18.000
J
i
t
t
e
r

V
o
z

(
m
s
)
1 Fluxo- BE UDP 8.917 8.167 16.833
Agregado- BE UDP 6.000 7.000 17.250
1 Fluxo- BE TCP 5.750 7.000 15.000
Agregado- BE TCP 5.500 6.750 11.333

Figura 7-7 Impacto do trfego de fundo (estudo da agregao de voz) - Valores mdios de jitter.
As taxas mdias de descarte de pacotes (Figura 7-8), no entanto, no
acompanharam as tendncias das mtricas anteriores, tendo o trfego com apenas 1 fluxo
apresentado os menores ndices. Na verdade, no necessariamente as taxas de descarte
devem ter a mesma inclinao das mtricas de delay e jitter. Resultados de testes individuais
mostraram, por exemplo, trfego de voz (principalmente agregado) com taxa de perda
consideravelmente alta (apresentando at uma certa distoro, em relao s demais

93

repeties) e com valores razoveis de delay e jitter. Recprocas tambm foram percebidas,
com taxas de perda pequenas e valores de delay e jitter acima da mdia.
0.000
0.500
1.000
1.500
2.000
2.500
3.000
3.500
4.000
4.500
5.000
P
e
r
d
a

V
o
z

(
%
)
Agregado- BE UDP 0.211 3.204 3.369
Agregado- BE TCP 0.000 2.157 2.686
1 Fluxo- BE UDP 0.000 0.028 1.008
1 Fluxo- BE TCP 0.000 0.009 0.004

Figura 7-8 Impacto do trfego de fundo (estudo da agregao de voz) - Taxas mdias de perda de pacotes.
7.2 Segunda etapa
O intuito desta fase avaliar efeitos no desempenho dos fluxos prioritrios de
voz, causados pela injeo na rede de trfego de melhor esforo de origem FTP, que uma
aplicao elstica (do tipo bulk traffic) e de rajadas mais longas do que servios como
web (http), por exemplo.
Da mesma forma que na 1
a
etapa, a disciplina de escalonamento utilizada aqui
foi a prio, tendo a banda 0 sido preenchida por uma fila do tipo BFIFO, com 1.600bytes, e
banda 1 sendo anexada, tambm, uma fila BFIFO, com 14.700bytes. A reserva de banda
efetuada no roteador interno, atravs da configurao da disciplina cbq, foi de 1.500Kbps.
Este estudo compreendeu a observao de agregados de voz compostos por 14
fluxos, modelados, novamente, com base no vocoder G.711, tendo o frame size de 60ms
(520bytes de payload). Foram gerados dois tipos distintos de trfego de background: TCP,
gerado pela ferramenta NETPERF e que ser aqui reconhecido como trfego no-FTP; e
FTP, gerado pelo programa ftp do Linux. Ambos tm pacotes com tamanhos totais de
1.448bytes (payload + cabealhos).

94

Comparou-se o desempenho dos agregados de voz frente injeo de trfego
BE, marcado por: 01 fonte TCP, 01 sesso FTP e, finalmente, 04 sesses FTP. Alm do
trfego prioritrio, a atuao desses fluxos de fundo tambm foi analisada.
No esquema FTP, o cliente foi a mquina qos2 e o servidor a mquina qos1.
Logo, o fluxo de fundo (FTP) percorreu a rede de qos1 a qos2, atravessando, com DiffServ
ativado, a interface de sada do roteador interno (eth1 de qos5), tal como nos experimentos
anteriores.
Houve a preocupao de se trabalhar com a mesma caracterizao para trfegos
de fundo no-FTP e FTP (com 01 sesso). Ou seja, foram avaliadas, primeiramente, as
caractersticas do trfego de FTP e, s depois, que se modelou o trfego no-FTP, de
forma a apresentarem as mesmas peculiaridades: tamanho dos pacotes, tempo de gerao e
vazo. Para 01 sesso FTP, utilizou-se arquivo nico com 5.090Kbytes, transferido em
torno de 28.8 segundos (com a presena de trfego de voz
61
). Tomou-se ento o mesmo
tempo para se gerar o trfego no-FTP, de maneira que correspondesse ao tempo de
transferncia FTP. Para 04 sesses FTP, fragmentou-se o arquivo empregado inicialmente
(de 5.090Kbytes) em 04 arquivos menores, de forma que a soma de seus tamanhos fosse
exatamente igual ao arquivo utilizado com 01 sesso
62
.
Os cenrios foram comparados, tomando-se como base o desempenho dos
fluxos prioritrios e de melhor esforo. A Figura 7-9 e a Figura 7-10 mostram o
desempenho do trfego de voz frente perturbao do meio atravs de fluxo TCP e da
transferncia de arquivos de dados. V-se, nas figuras, como a aplicao FTP agride mais
os fluxos de voz do que uma gerao puramente TCP, tendo ambos, como j colocado
antes, as mesmas caractersticas de transmisso, em termos de tamanho dos pacotes e
tempo de gerao. Pode-se imaginar os resultados em funo das naturezas elstica do
trfego FTP e oscilatria do protocolo TCP, com controle variado de congestionamentos.
Os resultados levam a crer que a gerao NETPERF (no-FTP) , mesmo que adaptativa s
condies da rede, mais previsvel e menos varivel que o servio FTP. Isto faz com que,
com FTP, o trfego concorrente (no caso aqui o de voz) ocupe mais tempo nas filas e

61
Tendo-se somente o trfego FTP na rede, a transmisso do arquivo durou 24 segundos.
62
Um com 1.250Kbytes e os outros trs com 1.280Kbytes cada.

95

apresente maior variao entre os perodos de enfileiramento, sendo isso mais evidente
ainda quando vrias sesses de longas transferncias ocupam a rede.
agregados de voz
8.000
8.500
9.000
9.500
10.000
10.500
11.000
11.500
12.000
D
e
l
a
y

(
m
s
)
Voz 8.667 9.500 11.667
No-FTP - 1 fluxo FTP 1 fluxo FTP 4 fluxos

Figura 7-9 Delay mdio do trfego de voz.
agregados de voz
6.000
26.000
46.000
66.000
86.000
106.000
126.000
146.000
J
i
t
t
e
r

(
m
s
)
Voz 10.500 19.917 135.333

Figura 7-10 Jitter mdio do trfego de voz.
A vazo mdia do trfego de fundo FTP ficou acima da alcanada pelo fluxo
no-FTP. Como este teve, em todas as repeties, valores de vazo inferiores aos de
trfego FTP (Figura 7-11), ento isto contribui para justificar o melhor desempenho do
agregado de voz com o trfego puramente TCP, j que, com trfego no-FTP, houve
menor ocupao da banda pelo trfego BE.

96

Com 4 sesses FTP, durante as repeties dos testes, chamou a ateno, ao
contrrio dos demais experimentos desta sesso, a grande variao dos valores de jitter
atribudos ao trfego prioritrio, ora com valores bem expressivos (acima de 280ms) e ora
com valores abaixo do 24ms
63
. Essa instabilidade motiva o alcance dos piores resultados de
delay e jitter, podendo ser observada na Figura 7-11. Ao contrrio, com 1 sesso FTP, os
valores de vazo foram invariveis, tendo, em todas as repeties, o valor de 1.440Kbps.
Vazo Nominal - Trfego BE
Valores por repetio
1200.00
1260.00
1320.00
1380.00
1440.00
1500.00
1560.00
1620.00
1680.00
1740.00
1800.00
1860.00
1920.00
V
a
z
o

B
E

(
K
b
p
s
)
Vazo 4 FTP 1688 1592 1608 1624 1856 1592 1552 1536 1624 1656 1592 1720
Vazo 1 FTP 1440 1440 1440 1440 1440 1440 1440 1440 1440 1440 1440 1440
Vazo no-FTP 1405 1409 1393 1411 1393 1387 1401 1388 1399 1399 1394 1408
1 2 3 4 5 6 7 8 9 10 11 12

Figura 7-11 Seqncias da vazo de melhor esforo.
Como j comentado, os cenrios em que se trabalha com trfego de fundo do
tipo FTP so, para efeito de comparao, semelhantes, com os arquivos transferidos tendo
exatamente os mesmos tamanhos, sendo que, com 4 sesses FTP, fragmentou-se o arquivo
utilizado com 1 sesso em 4 arquivos de tamanhos menores. No entanto, o que se percebeu,
ainda na Figura 7-11, foi que a vazo total dos 4 fluxos FTP ficou consideravelmente acima
da praticada por apenas 1 fluxo FTP
64
. Isto abre um leque para investigaes futuras, uma
vez que, dado o fenmeno da sincronizao global, deveria acontecer justamente o
contrrio, pois, teoricamente, com vrias sesses TCP/FTP, o controle ativo do protocolo
TCP tem maior atuao e as vazes de cada sesso tendem a diminuir, ainda mais se for
considerado que esse trfego concorre com mais 14 fluxos prioritrios de voz.

63
O jitter mdio com 4 fluxos FTP foi calculado em 135,3ms.
64
A vazo mdia com 4 fluxos FTP ficou em 1.636,67Kbps e com 1 fluxo FTP em 1.440,00Kbps.

97

Os grficos de taxas de perda e de vazo alcanada, referentes ao
comportamento dos fluxos de voz, so mostrados na Figura 7-12 e na Figura 7-13,
respectivamente. Eles praticamente confirmam os resultados das mtricas de delay e jitter,
com os nveis maiores de deteriorao da voz ocorrendo com trfego FTP. No entanto,
deve-se observar que, com vrias sesses de transferncia, h, em relao ao trfego com 1
sesso FTP, uma melhora muito discreta nas taxas de perda e de vazo alcanada do
trfego de voz. Isto demonstra uma estagnao dos resultados, provavelmente ocasionada
pela atuao da disciplina prio em evitar a tendncia de uma maior taxa de perda de pacotes
prioritrios de voz.
agregados de voz
0.000
1.000
2.000
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
P
e
r
d
a
s

(
%
)
Voz 2.688 4.801 4.614
Best Effort 0.000 1.302 7.271

Figura 7-12 Taxa mdia de perda de pacotes dos trfegos de voz e de BE.
Quanto ao trfego de fundo, observa-se que o mesmo se degrada com o
aumento do nmero de sesses de transferncia, mas, conforme j sinalizado na sesso
anterior, no mantm, como o trfego UDP, coerncia na relao perda x vazo. O fluxo
no-FTP, por exemplo, no sofreu descarte de pacotes e, no entanto, em relao aos demais
trfegos, foi o que atingiu o menor ndice na mtrica de vazo alcanada (80.42%). O
controle de fluxo e a elasticidade do comportamento dos trfegos TCP e TCP/FTP so os
responsveis pelo contra-senso dos valores mdios encontrados nos fluxos de fundo.

98

agregados de voz
78.00%
80.00%
82.00%
84.00%
86.00%
88.00%
90.00%
92.00%
94.00%
96.00%
98.00%
100.00%
V
a
z
o

A
l
c
a
n
a
d
a

(
%
)
Voz 97.23% 95.03% 95.23%
Best Effort 80.42% 85.71% 81.10%

Figura 7-13 Taxa mdia de vazo alcanada dos trfegos de voz e de BE.
Variaram-se, neste captulo, as caractersticas do trfego de fundo e observou-
se o impacto dessas mudanas no trfego modelado de voz. Os estudos foram realizados em
duas etapas.
Na 1
a
etapa, foram alterados tanto o tamanho dos pacotes (256, 512 e
1500bytes) quanto o tipo de protocolo de transporte (TCP e UDP) do trfego de melhor
esforo. Os teste mostraram que, em todas as mtricas de QoS, o trfego de fundo do tipo
UDP agrediu mais o agregado de voz do que o protocolo TCP, sendo que, quanto maior o
tamanho dos pacotes BE, maior foi a degradao do trfego prioritrio. Estudou-se, ainda
nesta etapa, o fator agregao, onde, nas mesmas condies de rede do estudo anterior, o
trfego de voz foi gerado sem agregao (com apenas 1 fluxo). Percebeu-se que os testes
ratificaram as tendncias apresentadas no Captulo 6, tendo os agregados obtido melhor
desempenho (em delay e em jitter) do que trfego sem agregao, independentemente do
tipo de protocolo de transporte utilizado.
A 2
a
etapa avaliou a influncia de trfego elstico de fundo do tipo FTP, com a
variao da quantidade de fontes. Viu-se que, com vrias sesses FTP, houve mais
degradao do trfego de voz do que com apenas 1 fluxo FTP. Trfego BE no-FTP (TCP
apenas) tambm foi testado e foi o que menos influenciou no desempenho do trfego

99

prioritrio. Em virtude do fenmeno da sincronizao global, alertou-se, com mltiplos
fluxos FTP, para a necessidade de futuras investigaes, uma vez que a vazo total desses
fluxos alcanou valores consideravelmente acima da praticada por apenas 1 fluxo FTP.

100

8. Concluso
O trabalho contribuiu na construo de uma plataforma de testes (testbed), com
estudos, em rede local composta por hardwares de baixo custo e softwares livres, de
impactos no desempenho de fluxos modelados de voz, a partir da utilizao do modelo de
diferenciao de servio em sistemas Linux.
Fez-se, inicialmente, uma contextualizao terica do assunto, abrangendo-se
aspectos bsicos da qualidade de servio e dos modelos sugeridos pelo IETF, sendo que,
para o servio diferenciado, houve um certo aprofundamento. Foram apresentados, logo
aps tal fundamentao, os itens relacionados ao ambiente de testes, com destaque para a
topologia da rede e para a metodologia adotada nos experimentos.
Verificando-se, atravs de experimentos com escalonadores diferentes, de que o
meio era capaz de diferenciar trfego, partiu-se para a modelagem de vocoders distintos de
udio, onde se percebeu que, utilizando-se o escalonador prio, a modelagem do vocoder
G.726, com pacotes de 120bytes, apresentou os menores atrasos e os menores ndices de
descarte de pacotes, mas, no entanto, apresentou as mais altas variaes de atraso entre
pacotes. O tamanho dos pacotes afetou diretamente no atraso e inversamente no atraso
entre pacotes do trfego modelado de voz. Um ambiente de sobrecarga de rede tambm foi
aplicado e as mesmas tendncias foram encontradas, confirmando assim os resultados
inicialmente colhidos. Ainda no estudo dos vocoders, agora com disciplina de
escalonamento do tipo FIFO (bfifo), que representou a ausncia de qualidade de servio na
rede, sem priorizao de trfego, embora se tivesse a preocupao de manter-se as mesmas
condies de transmisso de trfego do experimento com prio, os efeitos foram bem
diferentes. A modelagem do vocoder G.711, com pacotes de 520 bytes, obteve os melhores
resultados, em todas as mtricas.
Utilizou-se o testbed para um estudo comparativo do desempenho de agregados
de voz, gerados a partir de fontes distintas, com caractersticas contnuas (CBR) e de
atividade-silncio (ON-OFF). Observou-se que o trfego CBR obteve os menores valores
mdios de atraso e de descarte de pacotes. No entanto, o trfego ON-OFF conseguiu o
melhor desempenho no jitter. Foram analisadas, ainda neste estudo, os efeitos da agregao

101

de fluxos do tipo atividade-silncio, onde se variou o nmero de fluxos prioritrios de voz.
Viu-se que, com um maior nmero de fluxos, os melhores resultados foram atingidos,
confirmando assim o fator agregao como o princpio bsico do modelo DiffServ.
Foram avaliados tambm, num ambiente com priorizao de trfego (disciplina
prio), impactos no desempenho da modelagem de agregados de voz, causados pela variao
do trfego de fundo. Duas etapas foram realizadas:
- Na primeira etapa, o trfego BE recebeu variaes tanto no tipo de protocolo de
transporte utilizado quanto no tamanho dos pacotes. Constatou-se que o trfego
UDP, pela falta de mecanismos de controle de congestionamento, causa maior
influncia no desempenho do agregado de voz que fluxos do tipo TCP,
indiferentemente do tamanho do pacote BE. Em ambos os protocolos, quanto
maior o pacote de fundo, menor o desempenho dos fluxos de voz. Ou seja,
pacotes de fundo maiores, misturados aos de voz, fazem com que estes levem
mais tempo para atravessar a rede, influindo em sua degradao. Realizou-se
ainda nesta etapa um estudo de agregao, no qual se repetiram os testes, agora
com apenas 1 fluxo de voz sendo perturbado por trfegos de fundo UDP e TCP.
Observou-se que, para os atrasos e jitters mdios, os agregados conseguiram
melhor desempenho que o trfego de voz com apenas 1 fluxo, ratificando os
resultados obtidos no estudo da Sesso 6.2.(Agregao ON-OFF de fluxos
prioritrios).
- Na segunda etapa, avaliaram-se os efeitos de aplicaes FTP, com uma e quatro
sesses, nos fluxos de voz. A maior degradao do trfego prioritrio foi
observada com a injeo de 4 sesses FTP, o que possibilitar uma investigao
futura, uma vez que, dada a sincronizao global, quanto maior o nmero de
fluxos TCP, como h uma maior controle de transmisso das fontes geradoras,
menor deveria ser a vazo total na rede. Valores mtricos elevados e uma grande
instabilidade no trfego com 4 sesses FTP foram observados.
O trabalho definiu a mtrica taxa de vazo alcanada. Trata-se da razo
entre a vazo atingida pelos fluxos e a respectiva taxa de gerao aplicada. Os resultados
indicaram, em todos os experimentos com trfego UDP, uma complementao entre os

102

valores das taxas de perda de pacotes e de vazo alcanada, uma vez que, para qualquer
trfego no cooperante e numa mesma proporo, quanto maior o nmero de pacotes
descartados, menor a quantidade de bits recebidos no destino (e vice-versa). Trfego
TCP, ao contrrio, no apresentou coerncia na relao entre as taxas de perda e de vazo
alcanada, dada a prpria natureza do protocolo, que sempre influenciado por
mecanismos de controle de transmisso.
Houve uma sensvel preocupao no trabalho pela exposio das justificativas
de cada resultado, com a traduo dos grficos que expressam as mtricas de interesse.
Alm disso, imaginou-se que, para explicar o comportamento do trfego modelado de voz e
como ele influenciado pela rede, seria necessrio, tambm, justificar as tendncias dos
fluxos de perturbao do meio. Isto ocorreu em vrias experimentaes.
Pode-se levantar aqui algumas sugestes de trabalhos futuros, como:
- A topologia construda, numa rede local e controlada, no permite concluir os
resultados, segundo a classificao do ITU-T (ver Figura 3-9) para atrasos em
um sentido. Para uma visualizao mais realstica dessa mtrica, seria necessrio
estender geograficamente a rede, mant-la controlada, recalcular os atrasos
mdios e analisar a viabilidade sobre os resultados obtidos;
- O trfego modelado de voz deste trabalho foi estudado de uma forma
quantitativa. No entanto, fica a necessidade de analis-lo qualitativamente, no
mesmo testbed ou numa topologia mais estendida (o que seria mais interessante
ainda), com a aplicao de ferramentas especficas para isso, tais como
Netmeeting, Real Player ou outras;
- Pode-se utilizar a mesma plataforma de teste para uma avaliao, atravs do
servio diferenciado, de trfego modelado de vdeo no formato MPEG, com a
utilizao de mecanismos de gerenciamento ativo de filas, responsveis pela
associao de nveis de precedncias de descarte de pacotes, de acordo com o
tipo de quadro trafegado, tal como simulado em [55].
- O efeito da sincronizao global consiste na atuao simultnea de mecanismos
de controle de congestionamentos de protocolos, como o TCP. Tal fenmeno

103

pode criar uma situao em que a rede oscila freqentemente entre taxas
elevadas de transferncia, com perdas de pacotes, e vazes muito aqum da
capacidade da rede, podendo prejudicar o desempenho dos fluxos. Mecanismos
de gerenciamento ativo de filas, como os providos pela famlia de algoritmos
RED, em conjunto com o protocolo TCP, impedem, atravs da monitorao do
tamanho das filas de espera e da notificao de ocorrncias de perdas s fontes
geradoras, a sincronizao global e evitam o congestionamento da rede. Desta
maneira, necessita-se estudar com mais profundidade, num ambiente com
diferenciao de servio, a influncia da sincronizao global e dos mecanismos
ativos de filas no desempenho de trfego multimdia (voz e vdeo).

104

9. Referncias Bibliogrficas

[1] CROLL, A. e PACKMAN, E. Managing Bandwidth: deploying QoS in Enterprise
Networks. Prentice Hall, 1999.

[2] MARTINS, JOBERTO. Qualidade de Servio (QoS) em redes IP: Princpios
Bsicos, Parmetros e Mecanismos. UNIFACS, So Paulo, 2000.

[3] KAMIENSKI, CARLOS ALBERTO e SADOK, DJAMEL. Qualidade de Servio na
Internet. Minicurso SBRC 2000, maio 2000.

[4] XIAO, XIPENG. Providing Quality of Service in the Internet. Department of
Computer Science, Michigan State University, 2000.

[5] LEFELHOCZ, C. et al. Congestion Control for Best-Effort Service: Why We Need
A New Paradigm. IEEE network, janeiro 1996.

[6] BRADEN, R. et al. Recommendations on Queue Management and Congestion
Avoidance in the Internet. RFC 2309, abril 1998.

[7] SOARES, L. et al. Redes de Computadores: das LANs, MANs e WANs s Redes
ATM. Editora Campus, 1997.

[8] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO).
Information Technology Quality of Service Framework. ISO/IEC 13236, julho
1995.

[9] TEITELMAN, B. e HANSS, T. QoS Requirements for Internet2. Internet2 QoS
Work Group Draft, abril 1998.

[10] STARDUST.COM, INC. The Need for QoS. White Paper, julho 1999.

[11] FERGUSON, P. e HUSTON, G. Quality of Service: delivering QoS on the Internet
and in Corporate Networks. Wiley Computer Publishing, 1999.

[12] R. BRADEN; D. CLARK e S. SHENKER. Integrated Services in the Internet
Architecture: an Overview. RFC 1633, junho 1994.

[13] MIRAS, DIMITRIOS. Network QoS Needs of Advanced Internet Applications: A
Survey. Internet2 QoS Work Group, dezembro 2002.

[14] ARMITAGE, GRENVILLE. Quality of Service in IP Networks: Foundations for a
Multi-Service Internet. USA: Macmillan Technical Publishing, abril 2000.

[15] SHENKER, S.; PARTRIDGE, C. e GUERIN, R. Specification of guaranteed
quality of service. RFC 2212, 1997.

105

[16] WROCLAWSKI, J. Specification of the controlled-load network element service.
RFC 2211, 1997.

[17] OLIVEIRA, RENATO DONIZETE. Servios Diferenciados em redes IP
medies e testes para aplicaes envolvendo mdias contnuas. Abril 2001. Dissertao
de Mestrado Universidade Federal de Santa Catarina (UFSC). Santa Catarina.

[18] MOTA, OSCAR. Uma arquitetura adaptvel para proviso de QoS na Internet.
Maio 2001. Dissertao de Mestrado Pontifica Universidade Catlica do Rio de Janeiro.
Rio de Janeiro.

[19] ARINDAM, PAUL. QoS in data networks: Protocols and Standards. 1999.

[20] KOREN, T. et al. Enhanced Compressed RTP (CRTP) for Links with High Delay,
Packet Loss and Reordering. RFC 3545, 2003.

[21] POSTEL, J. Internet Protocol DARPA Internet Program Protocol Specification.
RFC 791, 1981.

[22] ALMQUIST, P. Type of Service in the Internet Protocol Suite. RFC 1349, 1992.

[23] NICHOLS, K.; BLAKE, S.; BAKER, F. e BLACK, D. L. Definition of the
differentiated services field (ds field) in the ipv4 and ipv6 headers. RFC 2474. 1998.

[24] ALMESBERGER, WERNER et al. A Prototype Implementation for the IntServ
Operation over DiffServ Networks. In Proceeding of the IEEE Globecom 2000, S.
Francisco, USA, novembro 2000

[25] MAMELI, ROBERTO e SALSANO, STEFANO. Use of COPS for IntServ
operations over Difffserv: Architectural Issues, Protocol design and Test-Bed
implementations. In Proceeding of the IEEE ICC 2001, Helsinki, junho 2001.

[26] DURHAM, D.; BOYLE, J.; COHEN, R. et al. The COPS (Common Open Policy
Service) Protocol. RFC 2748, 2000.

[27] RAJAN, RAJU et al. A Policy Framework for Integrated and Differentiated
Services in the Internet. IEEE Network, pp.36-41, setembro-outubro 1999.

[28] ALMES, G.; KALIDINDI, S.; ZEKAUSKAS, M. One-way Delay Metric for IPPM.
RFC 2679, setembro 1999.

[29] DEMICHELIS C; CHIMENTO P. IP Packet Delay Variation Metric for IP
Performance Metrics (IPPM). RFC 3393, 2002.

[30] HERSENT, OLIVER. Telefonia IP. So Paulo: Prentice Hall, 2002.

[31] WAGNER, KURT. Short Evaluating of Linuxs Token-Bucket-Filter (TBF)
Queuing Discipline. 2001.

106

[32] BLAKE, R.; BLACK, D. et al. An Architecture for Differentiated Services. RFC
2475, dezembro 1998.

[33] ZIVIANI, ARTUR; REZENDE, JOS F. DE; DUARTE, OTTO CARLOS.
Evaluating Voice Traffic in a differentiated services network. In Proceeding of the 17
th

International Teletraffic Congress ITC17, pp. 907-918, Salvador, Brazil, December
2001.

[34] B. DAVIE et al. An expedited forwarding PHB (Per-Hop Behavior). RFC 3246,
maro 2002.

[35] J. HEINANEN et al. Assured forwarding PHB group. RFC 2597, junho 1999.

[36] MOTA, OSCAR THYAGO JOS DUARTE DANTAS LISBA. Uma arquitetura
adaptvel para proviso de QOS na Internet. 2001. Dissertao de Mestrado Pontifica
Universidade Catlica do Rio de Janeiro. Rio de Janeiro.

[37] QBONE home page. Disponvel em http://qbone.internet2.edu/.

[38] ALMESBERGER, WERNER; SALIM, JAMAL HADI.; KUZNETSOV, ALEXEY.
Differentiated Services on Linux. In Proceeding of the Globecom99, pp. 831-836,
dezembro 1999.

[39] RADHAKRISHNAN, S. Linux Advanced Networking Overview, Version 1. The
University of Kansas,1999.

[40] SEMERIA, CHUCK. Supporting Differentiated Service Classes: Queue
Scheduling Disciplines. USA: Juniper Networks, dezembro 2001.

[41] HUBERT, BERT. Linux Advanced Routing & Traffic Control HOWTO. 2002.

[42] PRIOR, RUI PEDRO DE MAGALHES CLARO. Qualidade de Servio em Redes
de Comutao de Pacotes. 2001. Dissertao de Mestrado Faculdade de Engenharia da
Universidade do Porto. Porto, Portugal.

[43] GAO RESEARCH INC. G.726 Vocoder. Disponvel em
http://www.gaoresearch.com.

[44] MARKOPOULOU, ATHINA P.; TOBAGI, FOUAD A.; KARAM, MANSOUR J.
Assessment of VoIP Quality over Internet Backbones. In Proceeding of the IEEE
INFOCOM 2002, New York, junho 2002.

[45] ZIVIANI, ARTUR. Voz sobre servios diferenciados na Internet. Setembro 1999.
Dissertao de Mestrado Universidade Federal do Rio de Janeiro (UFRJ). Rio de Janeiro.

[46] SU, D.; SRIVASTAVA, J.; YAO, J. Investigating factors influencing QoS of
Internet phone. In Proceeding of the IEEE International Conference on Multimedia
Computing and System, pp. 308-313, junho 1999.

107

[47] ITU-T. One-way transmission time. Recomendao G.114. Maro 1993.

[48] SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time
Applications. RFC 1889, 1996.

[49] FERRARI, TIZIANA; PAU GIOVANNI; RAFAELLI, CARLA. Measurement
Based Analysis of Delay in Priority Queuing. In Proceeding of the IEEE Global
Telecommunication Conference Globecom 2001, S. Antonio, Texas, novembro 2001.

[50] LEOCDIO, MRCIO PARENTE; RODRIGUES, PAULO AGUIAR. Uma
ferramenta para Gerao de Trfego e Medio em Ambiente de Alto Desempenho.
Anais do 18
o
SBRC, Belo Horizonte, MG, pp. 321-336, maio 2000.

[51] NAVAL RESEARCH LABORATORY (NRL). The Multi-Generator (MGEN)
Toolset. Disponvel em http://manimac.itd.nrl.navy.mil/MGEN.

[52] JONES, R. Netperf. 1995. Disponvel em http://www.netperf.org/ netperf/
NetperfPage.html.

[53] V. JACOBSON; C. LERES; S. MCCANNE. Tcpdump, a network packet capture
program. 1989. Disponvel em http://www.tcpdump.org.

[54] FERRARI, TIZIANA. End-to-End Performance Analysis with Traffic
Aggregation. Computer Network Journal, vol. 34, no. 6, pp. 905-914, dezembro 2000.

[55] ZIVIANI, ARTUR; REZENDE, JOS FERREIRA DE; DUARTE, OTTO CARLOS.
Vdeo MPEG sobre servios diferenciados. Anais do 19
o
Simpsio Brasileiro de
Telecomunicaes 2001, Fortaleza, CE, 2001.

Evaluating the expedited forwarding of voice traffic in a differentiated services
network. International Journal of Communication Systems, vol. 15, no. 9, pp. 799-813,
novembro 2002.

Towards a differentiated services support for voice traffic. 1999. Anais do IEEE Global
Telecommunications 1999, Rio de Janeiro, RJ, 1999.

[58] TYAGI, ANURAG; MUPPALA JOGESH K.; MEER, HERMANN DE. VoIP
support on differentiated services using Expedited Forwarding. In Proceeding of the
IPCCC 2000, Phoenix, AZ, USA, pp. 574-580, fevereiro 2000.

[59] KOS, ANTON. Real-Time Applications Performance in Differentiated Service
Network. In Proceeding of the IEEE Region 10 International Conference on Electrical
and Electronic Technology, vol. 1, pp. 96-102, agosto 2001.

[60] KOS, ANTON. Performance of VoIP Applications in a Simple Differentiated
Services Network Architecture. In Proceeding of the International Conference on Trends
in Communications, 2001.

108

[61] NETWORK SIMULATION (NS). Disponvel em http://www-
mash.cs.berkeley.edu/ns/ ns.html.

[62] CASNER, S.; JACOBSON V. Compressing IP/UDP/RTP Headers for Low-Speed
Serial Links. RFC 2508, 1999.

[63] Skype home page. Disponvel em http://www.skype.com/.

Tese - Ricardo H. B. Azoubel PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tese - Ricardo H. B. Azoubel PDF

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDADE FEDERAL DO MARANHO

CENTRO DE CINCIAS EXATAS E TECNOLGICAS

Вам также может понравиться