PinottiFernandoLuiz M PDF

UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE TECNOLOGIA
Simulao e Emulao de
Trfeo Mul!im"dia em Rede# IP
Fer$a$do Lui% Pi$o!!i
Limeira
&'((
')*&'((
UNIVERSIDADE ESTADUAL DE CAMPINAS
FACULDADE DE TECNOLOGIA
Simulao e Emulao de
Trfeo Mul!im"dia em Rede# IP
Fer$a$do Lui% Pi$o!!i
Orientador: Prof. Dr. Varese Salvador Timteo
Dissertao apresentada Faculdade de
Tecnologia da niversidade !stadual de
"ampinas# como parte dos re$uisitos para a
o%teno do grau de &estre em Tecnologia
e 'novao.
Limeira
&'((
'
FICHA CATALOGRFICA ELABORADA POR SILVANA MOREIRA DA SILVA SOARES
CRB-8/3965
BIBLIOTECA UNIFICADA FT/CTL
UNICAMP

Ttulo em ingls: Simulation and emulation of multimedia traffic over IP network
Palavras-chave em ingls (Keywords):
1- Multimedia communication
2- Traffic models
3- Communication protocols
rea de concentrao: Tecnologia e Inovao
Titulao: Mestre em Tecnologia
Banca examinadora: Varese Salvador Timteo, Edson Luiz Ursini, Glio
Mendes Ferreira
Data da Defesa: 01-09-2011
Programa de Ps-Graduao em Tecnologia

Pinotti, Fernando Luiz, 1987-
P656s Simulao e emulao de trfego multimdia em redes
IP / Fernando Luiz Pinotti. Limeira, SP : [s.n.], 2011.

Orientador: Varese Salvador Timteo.
Dissertao (mestrado) Universidade Estadual de
Campinas, Faculdade de Tecnologia.

1. Comunicaes multimdia. 2. Modelagem de trfego.
3. Redes de computao - Protocolos. I. Timteo, Varese
Salvador. II. Universidade Estadual de Campinas, Faculdade
de Tecnologia. III. Ttulo. .

Dedi+a!,ria
(o meu $uerido pai# $ue independente de onde# estaremos sempre )untos.
'''
Arade+ime$!o#
Primeiramente gostaria de agradecer ao meu orientador# Professor Doutor Varese Salvador Timteo#
$ue seu apoio foi de enorme import*ncia nas decis+es e reali,a+es dos percursos desta dissertao# e#
principalmente o seu apoio no momento mais dif-cil $ue a vida nos fa, passar.
(o Professor Doutor !dson .ui, rsini pelo seu vasto con/ecimento e e0periencia# principalmente
na utili,ao do (1!2(.
m agradecimento especial a toda min/a fam-lia# por ter me dado a oportunidade de c/egar at3 a$ui.
(os meus amigos de faculdade e colegial pelo apoio e motivao.
(o Programa Santander# por ter me dado a oportunidade financeira de ter o privilegio de estudar na
niversidad Polit3cnica de &adrid.
4 "(P!S# pela %olsa de estudo# por proporcionar condi+es para $ue essa dissertao fosse reali,ada# e
a 2'"(&P# $ue sem ela nada seria poss-vel.
'V
RESUMO
!sta dissertao apresenta dois estudos# o primeiro trata de uma su%stituio do socket pela pil/a
T"P5'P u'P de um gerador de tr6fego multim-dia so%re 'P com o o%)etivo de manipularmos os campos
dos ca%eal/os 'P 7'pv8 Type of Service, e 'pv9 Traffic Class)# $ue sero utili,ados para a identificao
dos servios multim-dia. O gerador gera diferentes tr6fegos multim-dia simult*neos seguindo fun+es
de distri%ui+es con/ecidas utili,ando o conceito de thread. O segundo estudo trata de modelos de
simula+es utili,ando o simulador de eventos discretos (1!2(. Propomos tr:s diferentes modelos de
simulao $ue simulam am%ientes multim-dia# onde servios stream e el6stico so re$uisitados
simultaneamente pelos usu6rios. 2o modelo ; foram reali,ados simula+es propondo um estudo de
demanda de re$uisi+es dos usu6rios. Onde# tr:s cen6rios foram estudados. O primeiro# $uando ocorre
um aumento repentino de usu6rios# com isso aumentando o intervalo de re$uisi+es dos servios. O
segundo cen6rio# $uando a durao dos servios aumentam ocorrendo %lo$ueios de novos servios por
falta de recursos. ! o terceiro cen6rio 3 com relao ao "ontrole de (dmisso de "/amada 7"("< do
sistema. Os modelos = e > so am%ientes VP2# onde 3 estudado o Sojourn# tempo $ue o pacote leva
para c/egar ao host de destino. ( principal diferena entre os dois modelos 3 $ue o modelo = no
apresenta a implementao de atri%utos como jitter e lat:ncia. O jitter e lat:ncia influenciam no tempo
$ue leva para o $uadro ser entregue ao seu destino# podendo causar diversos pro%lemas nos servios
stream# como degradao da $ualidade do servio ou %lo$ueio do servio. O estudo de modelos de
simula+es 3 de grande import*ncia para a validao dos resultados o%tidos na emulao do gerador de
tr6fegos multim-dia# tendo em conta $ue na simulao os pacotes no so transmitidos atrav3s de um
meio f-sico# e no emulador so transmitidos de um host a outro utili,ando !t/ernet.
Palavras?c/aves: &odelos de tr6fego# "omunicao &ultim-dia# Protocolos de "omunicao.
V
A-STRACT
T/is dissertation presents t@o studies#t/e first is a replacement of a socAet for a T"P5'P stacA u'P of a
multimedia traffic generator over 'P in order to manipulate t/e fields of 'P /eaders 7'Pv8 TBpe of
Service and 'Pv9 Traffic "lass<# @/ic/ @ill %e used for t/e multimedia services identification. T/e
multimedia traffic generator generates simultaneous multimedia services follo@ing different @ell?
Ano@n distri%utions functions using t/e concept of t/read. ( second studB of simulation models is
propose using t/e discrete event simulator (1!2(# @e propose t/ree different simulation model @itc/
simulates multimedia environments# @/ere stream and elastics services are re$uired simultaneous %B
users. T/e model ; @ere performed simulations proposing a re$uest demand studB from t/e users.
C/ere t/ree scenarios @ere studied. T/e first @/en occurs a sudden increase of users# t/ere%B
increasing t/e range of re$uests of services. T/e second scenario @/en t/e lengt/ of services increases#
occurring %locAages of ne@ services due t/e lacA of resources# for e0ample# trunAs in a telep/onB
e0c/ange. T/e t/ird scenario is related to "all (dmission "ontrol 7"("< sBstem. &odels = and > are
VP2 environments# @/ere is studied t/e so)ourn# time t/at t/e pacAet taAes to reac/ t/e destination.
T/e main differences %et@een t/e t@o models is t/at t/e model = does not preset t/e attri%utes
implementation )itter and latencB. T/e )itter and latencB affects t/e time it taAes t/e frame to %e
delivered to its destination# maB cause various pro%lems in streaming services# suc/ as $ualitB of
service degradation or %locAing t/e service. T/e studB of simulation models are of great importance for
t/e emulationDs results validations of t/e multimedia traffic generator# taAing into account t/at t/e
simulation pacAets are not transmitted over a p/Bsical structure# and t/e emulation are transmitted from
one /ost to anot/er using !t/ernet .(2.

EeB?@ords: Traffic &odels # &ultimedia "ommunication# "ommunication Protocols
V'
LISTA DE FIGURAS
Fiura (. Perfil t-pico de um tr6fego de %locos.
Fiura &. Perfil t-pico de um tr6fego de transao.
Fiura /. Perfil t-pico de um tr6fego stream.
Fiura 0. 1elao entre tr6fego el6stico e tr6fego stream.
Fiura 1. 1eservas dos servios.
Fiura 2. 1epresentao es$uem6tica da &6$uina de !stado do Ferador.
Fiura 3. Segmento T"P# G=8H.
Fiura ). Datagrama DP# G=8H.
Fiura 4. .ao principal de c/ecagem de pacotes.
Fiura ('. Diagrama de %locos dos processos de transmisso de dados ao rece%er de um novo pacote.
Fiura ((. Diagrama de %locos dos processos de envio de um novo pacote.
Fiura (&. Diagrama de flu0o com as principais caracter-sticas do u'P.
Fiura (/. Tr6fego entre as interfaces. T25T(P e et/I atrav3s da ponte %rI.
Fiura (0. Workspace do (1!2(. &odelo de simulao ;.
Fiura (1. Juantidade de videoconfer:ncias em funo do intervalo m3dio entre re$uisi+es. ( lin/a
preta representa o nKmero total de videoconfer:ncias# a a,ul as conclu-das# e a vermel/a as perdas. (
durao m3dia da videoconfer:ncia foi fi0ada em LII segundos e "(" igual a =.
Fiura (2. Juantidade de v-deos on demand em funo do intervalo m3dio entre re$uisi+es. ( lin/a
preta representa o nKmero total de v-deos on demand# a a,ul as conclu-das# e a vermel/a as perdas. (
durao m3dia do v-deo on demand foi fi0ada em M=II segundos com desvio padro de LII segundos#
utili,ando funo de distri%uio normal e "(" igual a =.
Fiura (3. Trec/o destacado na Fig. ;9. "omportamento do v-deo on demand entre o intervalo >9II a
=;9II segundos.
Fiura (). Juantidade de v-deo clips em funo do intervalo m3dio entre re$uisi+es. ( coluna preta
representa o nKmero total de v-deo clips# a a,ul as conclu-das# e a vermel/a as perdas. ( durao
m3dia do v-deo clips foi fi0ada em >II segundos e desvio padro de ;NI segundos# utili,ando a
distri%uio normal e "(" igual a 8.
Fiura (4. Juantidade de videoconfer:ncias em funo da durao m3dia da videoconfer:ncia. ( lin/a
preta representa o nKmero total de videoconfer:ncias# a a,ul as conclu-das# e vermel/a as perdas. O
intervalo m3dio entre re$uisi+es da videoconfer:ncia foi fi0ado em >9II segundos e "(" igual a =.
Fiura &'. Juantidade de v-deos on demand em funo da durao m3dia do v-deo on demand. ( lin/a
preta representa o nKmero total de v-deos on demand# a a,ul as conclu-das# e a vermel/a as perdas. O
intervalo entre re$uisi+es do servio foi fi0ado em ;88II segundos e "(" igual a =.
Fiura &(. Juantidade de v-deo clips em funo da durao m3dia do v-deo clips. ( lin/a preta
representa o nKmero total de v-deo clips# a a,ul as conclu-das# e a vermel/a as perdas. O intervalo entre
re$uisi+es do servio foi fi0ado em LII segundos# e "(" igual a 8.
Fiura &&. Juantidade de videoconfer:ncias em funo ao nKmero m60imo de videoconfer:ncia
simult*neos. ( lin/a preta representa o nKmero total de videoconfer:ncia# a a,ul as conclu-das# e a
vermel/a as perdas. ( durao m3dia e intervalo entre re$uisi+es dos servios so >IIII e >9II
segundos respectivamente. m valor e0agerado de durao de servio foi utili,ado para podermos
visuali,ar o efeito das mudanas no nKmero m60imo de servios simult*neos.
Fiura &/. Juantidade de v-deos on demand em funo ao nKmero m60imo de v-deo on demand
simult*neos. ( lin/a preta representa o nKmero total de v-deos on demand# a a,ul as conclu-das# e a
vermel/a as perdas. ( durao m3dia e intervalo entre re$uisi+es dos servios so M=II e ;88II
segundos respectivamente.
V''
Fiura &0. Juantidade de v-deo clips em funo do nKmero m60imo de v-deo clips simult*neos. (
lin/a preta representa o nKmero total de v-deo clips# a a,ul as conclu-das# e a vermel/a as perdas. (
durao m3dia e intervalo entre re$uisi+es dos servios so >II e LII segundos respectivamente.
Fiura &1. Workspace do (1!2(. &odelo de simulao =.
Fiura &2. Tempo de Sojourn do servio de Dados, em segundos# em funo a variao do volume de
tr6fego Vo'P# em !rlang. ( lin/a preta o servio de Dados est6 com prioridade e a lin/a a,ul sem#
variando de O em O !rlang o volume de tr6fego do servio Vo'P.
Fiura &3. Trace Router do site @@@.uol.com.%r..
Fiura &). Trace Router do site @@@.%;.rs.
Fiura &4. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
tr6fego em !rlang. "omparao dos casos ( entre os diferentes valores de jitter# lat:ncia e perda 7Ta%.
;O# ;9 e ;M< do servio de Dados utili,ando distri%uio e0ponencial..
Fiura /'. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
tr6fego em !rlang. "omparao dos casos P entre os diferentes valores de jitter# lat:ncia e perda 7Ta%.
;O# ;9 e ;M< do servio de Dados utili,ando distri%uio e0ponencial.
Fiura /(. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
;O# ;9 e ;M< do servio de Dados utili,ando distri%uio /iper?e0ponencial.
Fiura /&. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
Fiura //. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
;O# ;9 e ;M< do servio de Dados utili,ando distri%uio Pareto.
Fiura /0. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
;O# ;9 e ;M< do servio de Dados utili,ando distri%uio Pareto Truncada.
tr6fego em !rlang. "omparao dos casos ( entre a distri%uio e0ponencial e /iper?e0ponencial. Os
valores de jitter# lat:ncia e perda so os da Ta%. ;M.
Fiura /). Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
tr6fego em !rlang. "omparao dos casos P entre a distri%uio e0ponencial e /iper?e0ponencial.
Valores de jitter# lat:ncia e perda da Ta%. ;M.
Fiura /4. Tela principal do (1!2(.
Fiura 0'. Par*metros do %loco ARRIV!
Fiura 0(. Par*metros do %loco "TR!
Fiura 0&. Par*metros do %loco C#$$S!
Fiura 0/. "onfigurando Conditions.
Fiura 00. Par*metros do %loco ASSI%"!
Fiura 01. "onfigurando (ssocia+es.
Fiura 02. Par*metros do %loco &R$CSS!
Fiura 03. Par*metros 'ueue do %loco &R$CSS!
V'''
Fiura 0). Par*metros do %loco (&ART!
Fiura 04. Par*metros do %loco )AV!
Fiura 1'. Par*metros do %loco Varia*les!
Fiura 1(. Par*metros do %loco Simulate.
'Q
LISTA DE TA-ELAS
Ta5ela (. Principais servios multim-dia e suas respectivas categorias de tr6fego.
Ta5ela &. Va,o t-pica das aplica+es.
Ta5ela /. Prioridades para tr6fego multim-dia.
Ta5ela 0. "aracter-sticas dos servios gerados na simulao do (rena.
Ta5ela 1. "aracter-sticas dos servios gerados na emulao do Ferador de Tr6fego &ultim-dia.
Ta5ela 2. Valor dos par*metros iniciais utili,ados para a simulao.
Ta5ela 3. Par*metros de intervalo# durao e tr6fego dos servios.
Ta5ela ). Sa-das do servio de Dados com prioridade e sem prioridade. Sem prioridade 7SemP6 !odos
os servios esto utili,ando a mesma prioridade. "om prioridade 7ComP6 o servio de Dados possui
uma prioridade inferior aos demais.
Ta5ela 4. 2Kmero m60imo de servios simult*neo. O servio c*mera 'P possui um asterisco por$ue 3
um servio cont-nuo# no envolvendo par*metros como "(" e prioridade. ! o servio de Dados# 3
influenciado pelo volume do tr6fego stream.
Ta5ela ('. 1esultados das ;I replica+es e a media de cada servio. Todos os servios esto utili,ando
a mesma prioridade. (s Sa-das TipoRTa representam o tempo de sojourn dos servios# dado em
segundos. ( sa-da o*s TipoRTa so a $uantidade total de servios gerados.
Ta5ela ((. 1esultados das ;I replica+es e a media de cada servio. O servio de Dados est6 com uma
prioridade inferior aos demais servios. (s Sa-das TipoRTa representam o tempo de sojourn dos
servios# dado em segundos. ( sa-da o*s TipoRTa so a $uantidade total de servio gerado.
Ta5ela (&. "omparao do sojourn nos casos (#P e " do servio de Dados# distri%uio e0ponencial.
tili,ando MI !rlang.
Ta5ela (/. "omparao do sojourn nos casos (#P e " do servio de Dados# distri%uio /iper?
e0ponencial. tili,ando MI !rlang.
Ta5ela (0. "omparao do sojourn nos casos (#P e " do servio de Dados# distri%uio Pareto.
Ta5ela (1. Valores dos atri%utos +itter e (traso em segundos e Perda em porcentagem# dos seis
servios do modelo.
servios do modelo.
servios do modelo.
Ta5ela (). Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela (4.Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Ta5ela &'. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela &(. Tempo Sojourn do servio de Dados# P;sem prioridade# P= com prioridade.
Ta5ela &&. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela &/. Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Ta5ela &0. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela &1. Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Ta5ela &). Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela /'. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Q
Ta5ela /(. Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Ta5ela /&. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela //. Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Ta5ela /0. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela /1. Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Ta5ela /). Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela 0'. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela 0(. Tempo Sojourn do servio de Dados# P; sem prioridade# P= com prioridade.
Q'
SUM7RIO
;. 'ntroduo S.........................................................................................................................;
=. &odelos de fontes de tr6fego.................................................................................................>
>. Ferador de tr6fego &ultim-dia S.........................................................................................;M
8. Pil/a T"P5'P...........................................................................................................................=>
O. &odelos de Simulao...........................................................................................................>>
9. "onclus+es.............................................................................................................................98
Q''
(8 I$!roduo
Os sistemas emergentes de comunicao de %anda larga esto possi%ilitando cada ve, mais a
introduo de diversas aplica+es multim-dia com alto grau de comple0idade $ue e0igem uma ta0a de
dados elevada. (plica+es em tempo real de v-deo# videoconfer:ncia e 6udio so %ons e0emplos.
!$uipamentos como o "1S?> 7Carrier Routin, System< da "isco# vem sendo um contri%uidor forte nas
redes de alta velocidade# proporcionando uma capacidade de >== T%ps# tr:s ve,es maior do $ue a sua
verso anterior# "1S?;# possi%ilitando suprir tais aplica+es em grande escala.
2o passado# redes multim-dia como 'PTV# tiveram limita+es pela %ai0a penetrao da %anda
larga e pelo custo relativamente elevado de instalao de ca%eamento capa, de transportar as
informa+es de forma vi6vel na casa do assinantes. 2os anos $ue se seguiram# no entanto# o servio de
'PTV residencial cresceu a um ritmo acelerado# estima?se disponi%ilidade de mais de 8II mil/+es de
residencias em =I;I por todo o glo%o e as pes$uisas mostram um aumento na migrao de usu6rios
cada ve, maior G;H.
O nKmero de assinantes glo%ais de 'PTV deve crescer de =N mil/+es em =IIL para N> mil/+es
em =I;> G=H. !uropa e Tsia so os principais territrios em termos da grande $uantidade de assinantes.
!m termos de servios# a !uropa e (m3rica do 2orte geram uma maior parcela de rendimento glo%al#
devido (1Ps 7Avera,e Revenue &er -ser< muito %ai0a na "/ina e Undia 7(1P 3 o valor m3dio do
rendimento de uma empresa de coleta de cada usu6rio por m:s. Tais como servios e0tras# tais como
planos de dados# mensagens e conteKdo para do.nload<. (s receitas do mercado glo%al de 'PTV esto
previstas para crescer de V ;= %il/+es em =IIL para V >N %il/+es em =I;> G=H.
&uitos fornecedores mundiais de telecomunica+es esto e0plorando o 'PTV como uma nova
oportunidade de receita de seus mercados e0istentes e como uma medida defensiva contra a invaso de
mais servios convencionais de TV a ca%o. (l3m disso# /6 um nKmero crescente de instala+es 'PTV
dentro de escolas# universidades# empresas e institui+es locais. 2o setor industrial# 'PTV 3 uma
realidade e empresas de telecomunica+es ao redor do mundo continuam a aumentar suas
implementa+es comerciais de servios de 'PTV.
Frandes fa%ricantes de e$uipamentos de telecomunica+es como a (lcatel e a Siemens )6
esta%eleceram parceria e reali,am acordos com grandes operadoras de telecomunica+es. Diversas
empresas como a (lcatel# (TWT# PT Vision# DT e muitas outras esto tra%al/ando com a &icrosoft e#
)untos# esto alimentando grandes implementa+es como o &ediaroom# servio de 'PTV G>H.
( Siemens comprou uma pe$uena compan/ia c/amada &Brio em =II9 $ue fornece servios de
'PTV. ( empresa conta com mais de MO operadoras regionais nos !(# %em como algumas operadoras
no e0terior# incluindo como clientes a 1oBal EP2 /olandesa Telecom# a Pelgacom na !uropa e
Datanet@orA (dvanced "ommunications# na Tail*ndia# G8H. ( !ricsson foi uma das ultimas grandes
empresas a entrar nessa %atal/a suprindo com produtos de rede e soft@ares 'PTV.
Xuntamente com o 'PTV surgem novas tecnologias e servios $ue permitem $ue as empresas de
telecomunica+es implementem servios avanados como a alta $ualidade de canais multicast 'PTV#
YDTV %aseada em 'P# e Whole #ome /edia "et.orkin, 7CY&2<. Outra vantagem da evoluo dos
servios de 'PTV inclui a personali,ao e acesso imediato a uma vasta variedade de conteKdos em
demanda digital.
!m GOH um modelo para tr6fego multim-dia 3 apresentado# neste caso v-deo stream utili,am
&P!F?8. 2o $ual o tr6fego 3 dissociado gerado por uma aplicao multim-dia em um nKmero de
componentes %6sicos e resulta um modelo de tr6fego para cada componente. Os componentes so
integrados utili,ando um modelo de fonte# no $ual um %raphical -ser Interface 7F'< 3 utili,ado para
facilitar o processo de modelagem do trafego.
;
2en/um modelo de tr6fego comumente utili,ado 3 capa, de capturar o comportamento fractal
de um tr6fego !t/ernet G9H. "om o proposito de modelar a nature,a fractal do tr6fego !t/ernet# os
autores G9H desenvolveram m3todos para aumentar a performance da sua autossimilaridade utili,ando
processos estoc6sticos Pro@nian.
!mGMH# os autores modelam tr6fegos &P!F?8 em n-vel de %roup of &ictures 7FoP< utili,ando
modelos autorregressivos. ( caracter-stica de um tr6fego de v-deo streamin, tam%3m depende da
compresso adotada. O padro &P!F8 e Y.=9> GNH so candidatos potenciais de codec para prover
multim-dia so%re redes sem fio e com fio. Poss-veis GLH fun+es de distri%uio para servios de
videoconfer:ncia utili,ando compresso &P!F?8 mostram $ue a compresso do tipo Pearson V possui
uma preciso mais apurada.
ma analise estat-stica de amostra emp-rica de v-deo VP1 3 o%tido aplicando compress+es
entre os $uadros de v-deo de um filme G;IH. &odelos de .avelet para trafego de v-deo VP1
proporcionam tr6fegos simult*neos de v-deo de longo e curto alcance# com a capacidade de redu,ir a
depend:ncia temporal de forma significativa G;;H.
Simula+es de priori,ao de filas de pacotes %aseado na garantia de Jualidade de Servio
7JoS< em portas de entrada de s.itch de alto desempen/o possi%ilita assegurar JoS de tr6fegos
multim-dia G;=H.
Vale apana ressaltar $ue neste tra%al/o veremos modelos anal-ticos# simula+es e emula+es de
tr6fego multim-dia stream e el6stico# seguindo diferentes fun+es de distri%ui+es.
(8( Simulao 9 Emulao
Os estudos de simulao au0iliam os pro)etistas na concepo de algor-tmos de controle de
tr6fego a Jualidade de Servio e tam%3m aperfeioam a relao custo5desempen/o da rede G;>H. 2o
desenvolvimento de um programa de simulao para rede de comunica+es# /6 uma necessidade de
modelar as demandas dos usu6rios aos recursos de rede# caracteri,ar os recursos e0igidos para atender a
essas demandas e estimar o desempen/o %aseado em dados de sa-da gerados pela simulao G;8H.
( simulao pode ser definida como: Zt3cnica em $ue se utili,a de um simulador# considerando?
se o simulador como um o%)eto ou representao parcial ou total de uma tarefa a ser replicada[ G;OH.
!ssa definio tra, dois importantes aspectos necess6rios simulao: o primeiro di, respeito ao
tratamento %aseado em tarefas# no $ual se enfati,a o $ue deve e como deve ser feito para $ue se atin)a o
o%)etivo proposto# en$uanto o segundo 3 a relao com o simulador propriamente dito# $ue so as
formas de interao com o simulador.
2a 6rea de computao# um emulador 3 um soft@are $ue reprodu, as fun+es de um
determinado am%iente# a fim de permitir a e0ecuo de outros soft@ares so%re ele. Pode ser pela
transcrio de instru+es de um processador alvo para o processador no $ual ele est6 rodando# ou pela
interpretao de c/amadas para simular o comportamento de um /ard@are espec-fico. O emulador
tam%3m 3 respons6vel pela simulao dos circuitos integrados ou c/ips do sistema de /ard@are em um
soft@are. Pasicamente# um emulador e0p+e as fun+es de um sistema para reprodu,ir seu
comportamento# permitindo $ue um soft@are criado para uma plataforma funcione em outra.
Os am%ientes de redes computacionais geralmente so formados por camadas. ( $uantidade e o
papel de cada camada pode variar de acordo com o am%iente. (lguns am%ientes so puramente f-sicos
como os terminais de mainframe e# portanto# na sua emulao ca%e apenas o tratamento dos dados
enviados do terminal ou para ele# e reprodu,ir a interao com o usu6rio. Outros am%ientes podem no
possuir um firm.are 7algumas ve,es c/amado de %ios<# sendo $ue os programas $ue sero e0ecutados
con/ecem todo o /ard@are e sua emulao seria %asicamente a interpretao das c/amadas ao
=
/ard@are para reprodu,ir seu comportamento. (lguns am%ientes possuem firm.are mas no possuem
sistema operacional. 2esse casos 3 necess6rio emular tam%3m o firm.are ou o%ter um com o
fa%ricante.
Devemos distinguir o conceito de emulao do conceito de simulao# tendo em conta $ue o
segundo no corresponde codificao precisa do comportamento de um sistema# mas sim deduo
de modelos a%stratos de funcionamento. ( diferena entre os dois conceitos situa?se entre a produo
de analogia e a produo de s-ntese G;9H.
>
&8 Modelaem de fo$!e# de !rfeo
( tecnologia de transmisso em redes multim-dia tem proporcionado uma integrao de v-deo#
vo, e dados. Os servios podem ser divididos em dois tipos distintos: stream# como 6udio e v-deo e# os
$ue no possuem necessidade de serem em tempo real# denominados de el6sticos# $ue so os servios
de dados.
Discutiremos duas categorias de aplica+es de acordo com as restri+es temporais. 2o conte0to
do protocolo 'P a aplicao em tempo real fre$uentemente so associadas com o protocolo de
transporte DP# e aplicativos $ue no re$uerem tempo real associadas com o protocolo T"P. !m
aplica+es em tempo real# a se$u:ncia dos pacotes so definidos pela fonte. Os pacotes c/egam ao seus
destinos respeitando a se$uencia adotada pela fonte do transmissor. "aso isso no ocorra ca%e ao
receptor ordenar novamente os pacotes. (lgumas varia+es nos valores de delay e jiiter so permitidas
sem $ue /a)a grandes perdas e se os limites so respeitados.
!m aplica+es $ue no so em tempo real# as fontes no possuem uma ta0a de pacotes definida.
(s atividades de transfer:ncia de dados toleram variao de delay e jitter com perdas. "om isso no
temos uma $ualidade de servio em termos de comparao a aplica+es em tempo real 7delay# jitter<. \
necess6rio suprir uma ta0a de %its nominal. !sse tipo de aplicao %aseando?se em T"P gera tr6fego
Z!l6stico[ 7tr6fego el6stico e stream 3 definido no final do capitulo =.;< com as seguintes
caracter-sticas:
( ta0a da fonte de tr6fego varia de um pacote a outro pacote de acordo com a )anela de
congestionamento do T"P.
( ta0a de %its da fonte de tr6fego muda $uando a fonte detecta a perda de um pacote e fa, a
sua retransmisso.
( ta0a de %its da fonte de tr6fego depende do tempo da ida e da volta 1TT. 1TT 3 o tempo
necess6rio para o pacote c/egar no seu destino mais o tempo necess6rio para o ("E retornar
para a fonte.
( maior diferena entre estas duas categorias 3 o comportamento do aplicativo so%re as
condi+es da rede. ( ta0a de %its dos aplicativos DP so independentes da rede e determinados pela
fonte# en$uanto $ue a ta0a de %its dos aplicativos T"P variam de uma rede para outra. 'sso ocorre
por$ue normalmente o protocolo DP utili,a valores de codecs fi0os# e0igindo $ue /a)a uma ta0a de
%anda dispon-vel no minimo igual ou superior do codec $ue o servio utili,a. "aso essa condio no
se)a satisfeita ocorrer6 degradao da $ualidade do servio# mal funcionamento# ou dependendo da
situao no poder6 /aver o servio.
2o "apitulo > veremos com mais detal/es os protocolos de transporte T"P5'P e DP.
&8(8 Modelaem de +om:o$e$!e# de !rfeo mul!im"dia
(plicao multim-dia consiste em uma integrao de dois ou mais tipos de m-dia. m am%iente
simples como uma pro)eo de uma aula pode conter aplica+es de 6udio# v-deo e dados# sendo $ue
cada aplicao utili,a um tipo de tratamento de tr6fego. &esmo se duas aplica+es tem os mesmos
tipos de m-dia# a $uantidade de dados gerados e as estat-sticas do processo de gerao de dados podem
ser diferentes. Por conse$u:ncia# em lugar de dedu,ir um modelo de tr6fego para cada aplicao# 3
mais significativo identificar padr+es de tr6fego comuns a um grande nKmero de aplica+es multim-dia
GOH.
8
O primeiro passo na modelagem de tr6fego multim-dia so os algoritmos necess6rios para gerar
padr+es de tr6fego de cada componente# tais como Ploco# Transao# e Streamin,. Os algoritmos
apenas fornecem os procedimentos para a gerao de tr6fego. Para gerar um padro de tr6fego
especifico de uma aplicao multim-dia# os par*metros do modelo devem ser especificados.
Trfeo de -lo+o
Para definir uma fonte de tr6fego de %locos precisamos especificar a funo de distri%uio e os
par*metros correspondentes para cada uma das seguintes vari6veis:
2Kmero de Ploco por sesso.
Taman/o do Ploco.
Tempo de c/egada dos Plocos.
O intervalo possi%ilita o uso de fun+es de distri%uio continuas mostradas na Ta%. ;. (fim de
especificar o nKmero de %locos por sesso# uma variao discreta 3 necess6ria. 'sso pode ser feito
usando a distri%uio de Poisson ou geom3trica.

Fiura (. Fr6fico $ue representa um perfil t-pico de um tr6fego de %locos.

Trfeo de Tra$#ao
O tr6fego de transio consiste em altera+es ZO2[ e ZOFF[. Durante o per-odo ZO2[ pacotes
so gerados continuamente. (s seguintes vari6veis so necess6rias para definir uma sesso:
Durao da Sesso.
Durao O2.
Durao OFF.
Taman/o do pacote.
'ntervalo de c/egada dos pacotes durante o per-odo O2.
Para cada vari6vel# uma funo de distri%uio pode ser usada e os par*metros correspondentes
para as distri%ui+es devem ser especificadas.
Fiura &. Fr6fico $ue representa um perfil t-pico de um tr6fego de transao.
O
Tamanho
do arquivo
Tempo
Tamanho
do arquivo
Tempo
on on off off
Trfeo Stream
( fonte do tr6fego stream emite unidades de dados em per-odos sem silencio significativo# uma
representao es$uem6tica pode ser visto na Fig >. (l3m disso# 3 prov6vel $ue se manten/a ra)adas em
diferentes escalas de tempo 7devido os c/amados efeito de auto?similaridade< G9H. &odelos de auto?
regressivos GMH produ,em tr6fego com uma e0ponencial deteriorando a funo de autocorrelao. (
caracter-stica de um tr6fego de v-deo stream tam%3m depende da compresso adotada. O padro
&P!F?8 e Y.=9> GNH so candidatos potenciais de codec para prover multim-dia em redes .ireless# por
e0emplo.
ma fonte de ta0a constante de %its# especificando a ta0a de %its.
ma fonte de ta0a de %its vari6vel com o modelo auto?regressivo G;MH.
ma fonte de ta0a de %its vari6vel utili,ando o modelo F?(1'&( G;IH.
ma fonte de ta0a de %its vari6vel com o modelo Cavelet G;;H.
Fiura /. Fr6fico $ue representa um perfil t-pico de um tr6fego stream.
Ide$!ifi+ao da Ca!eoria de um !rfeo Mul!im"dia
Para modelar uma aplicao multim-dia# num emulador ou simulador utili,ando um ou mais dos
componentes %6sicos descritos acima# primeiramente deve?se fa,er a sua identificao. (plica+es
multim-dia normalmente geram traos de tr6fego# onde os componentes podem ser identificados a
partir de suas fontes. &esmo se dois componentes so origin6rios da mesma fonte# os pacotes
geralmente podem ser identificados por marca+es ade$uadas. 2o header do T"P5'P# essas marca+es
so identificadas no campo Traffic Class ou ToS do pacote enviado ou rece%ido. Sempre $ue c/ega ou
se transmite um novo pacote 3 especificado nesse campo $ual o tipo de servio utili,ado. 2o 'pv8 esse
campo 3 c/amado de ToS $ue 3 composto de N %its e no 'pv9 de Traffic Class $ue tam%3m 3 composto
de N %its. 2a Ta%. ; iremos destacar os principais tipos de aplica+es e suas respectivos modelos.
9
Servios Ploco Transao Streaming
Orientao de .ocali,ao
Pes$uisa de V]o
mpresas 0 "e,1cios
!ntrada de pedido
&ensagem
Palestras em sala
&ensagens de imagem
&ensagem multim-dia
V-deo &ensagem
PD( Virtual
ntretenimento m1vel
Filmes pe$uenos ou curtos
&usicas
Tudio Streaming
Xogos moveis
Telefone com v-deo
"/at mvel
"omercio mvel
&a$uinas de venda autom6tica
"ontrole remoto
&edio remota
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Ta5ela (. Principais servios multim-dia e suas respectivas categorias de tr6fego.
A5ordaem do Trfeo em Flu9o
2a a%ordagem proposta neste tra%al/o de validao do modelo de tr6fego /6 uma diferena. Os
tipos de tr6fego normalmente so descritos como %loco# transao# e stream. ! utili,am o conceito de
pacotes. Por outro lado estamos utili,ando o conceito de flu0o. O flu0o 3 %asicamente definido para o
caso tr6fego el6stico# em $ue considera?se $ue a sesso T"P 3 encerrada aps um certo tempo sem a
ocorr:ncia de pacotes para a origem ou destino. 2o tr6fego stream /6 um flu0o natural $ue permanece
ativo en$uanto durar a aplicao.
Para efeito da aplicao do conceito de flu0o os tipos o tr6fego so divididos em stream e
el6stico. 2ossa definio de stream5el6stico 3 em relao ao JoS. Pasicamente o stream tolera perda#
mas no tolera atraso# en$uanto o el6stico tolera atraso mas no tolera perda.
O stream 3 modelado como trafego de transao para aplica+es interativas $ue re$uer servios
em tempo real. Seu perfil 3 um flu0o de dados com altas ta0as de utili,ao $uando ativo# e com alta
prioridade no canal pois no tolera atrasos. Tr6fegos com esse perfil usaro o conceito de stream# por
e0emplo v-deo e vo,. O protocolo $ue mel/or se ad3$ua a esse perfil 3 o DP# tendo como principais
caracter-sticas um sistema de transmisso simples comparado ao T"P# sem sinali,ao de tr6fego para
fornecer confia%ilidade# ordem de c/egada dos pacotes# ou perca de pacotes# dessa forma garantindo
atrasos redu,idos.
M
O el6stico por outro lado possui %ai0a prioridade no canal. \ modelado como fontes O2?OFF
em relao ao volume de dados a serem transmitidos# e utili,ado para aplica+es no interativas. (
caracter-stica de elasticidade de tr6fego 3 devida %asicamente ao comportamento din*mico de
protocolos do tipo T"P# $ue garante a integridade da informao reali,ando retransmisso caso algum
pacote no se)a entregue.

Fiura 0. Desen/o es$uem6tico comparando caracter-sticas de tr6fego el6stico e tr6fego stream.
&8& Fu$;e# de Di#!ri5uio
(s distri%ui+es de pro%a%ilidade mais utili,adas# e mesmo em desempen/o de tr6fego e
pro%lemas de confia%ilidade# so as distri%ui+es e0ponencial e normal. O mesmo procedimento pode
ser seguido para v6rios outros tipos de distri%uio de pro%a%ilidade# cont-nuas ou discretas.
O comportamento de cada servio pode diferir de uma rede para outra apresentado diferentes
distri%ui+es. (%ai0o so descritas algumas das distri%ui+es. Ser6 feita uma %reve descrio das
distri%ui+es e situa+es nas $uais so aconsel/6veis sua utili,ao.
Di#!ri5uio E9:o$e$+ial
( distri%uio e0ponencial 3 utili,ada $uando se dese)a analisar o espao ou intervalo de
acontecimento de um evento# utili,ada para eventos cont-nuos. ( pro%a%ilidade para um certo tempo e
espao entre eventos sucessivos# ocorrendo em um processo de Poisson. \ comumente utili,ado para
intervalos entre c/egadas. ( funo densidade de pro%a%ilidade 7PDF< da distri%uio e0ponencial 3
mostrada a%ai0o:
f ( 2 3 \)=\e
\2
,
7;<
onde 0 ^ I e > 0 so os par*metros da distri%uio.
N
Elstico Stream
Tipo de
Trfego
UDP TCP/IP
Protocolo
ualidade
de
!ervi"o
Tolera Perdas
#$o Tolera %traso
%lta Prioridade
#$o Tolera Perdas
Tolera %traso
&ai'a Prioridade
()deo* (o+* ,udio E-mail* .e/
!ervi"o
Di#!ri5uio de <ei5ull
( distri%uio de Cei%ull# nomeada pelo seu criador Caloddi Cei%ull# 3 uma distri%uio de
pro%a%ilidade cont-nua . ( distri%uio de Cei%ull utili,a?se a para modelar o tempo entre fal/as de
e$uipamentos. !m redes# um e0emplo 3 a sua utili,ao no modelamento de transa+es. Pode
representar o per-odo $ue se situa um par*metro 7on ou off<. ( funo densidade de pro%a%ilidade de
Cei%ull de vari6vel aleatria 2 3 e0pressa por:
f ( 2 3 \, k)=
k
\
(
2
\
)
k;
e
( 2 /\)
k
,
7=<
onde 2 ^ I e k _ I# e k 3 o par*metro de taman/o# e ` _ I 3 o par*metro de escala da distri%uio. Sua
funo de distri%uio cumulativa 3 uma e0tenso da funo e0ponencial . ( distri%uio Cei%ull 3
relacionada a uma s3rie de outras distri%ui+es de pro%a%ilidade# em particular# pode descrever uma
interpolao entre a distri%uio e0ponencial 7k a ;< e a distri%uio 1aBleig/
7k a =<.
Di#!ri5uio de Pare!o
( distri%uio de Pareto foi introdu,ida primeiramente pelo economista italiano Vilfredo Pareto
em ;NLM. Desde ento muitos pes$uisadores a utili,aram em diversas 6reas. \ uma distri%uio de
pro%a%ilidade $ue modela fatos dos campos social# cient-fica# industrial e muitos outros tipos de
fen]menos o%serv6veis. Fora do campo da economia# 3 s ve,es referida como a distri%uio de
Pradford. ( funo densidade de pro%a%ilidade da distri%uio Pareto 3:
7><
onde 0 _ 0m _ I e 0m 3 o valor minimo do 0. ( fam-lia de distri%ui+es de Pareto so parametri,ados
por# 0m e b# onde b 3 o -ndice de Pareto.
Dentre as vari6veis $ue assumem comportamento de distri%uio Pareto# e $ue esto ligadas
an6lise de tr6fego em redes podem ser citados:
2Kmero de cone0+es em uma ra)ada de uma seo FTP.
Taman/o das ra)adas em %Btes.
Taman/o do ar$uivos.
Tempo de "P consumido por processos.
Per-odo ocioso 7en$uanto no /6 tr6fego de dados<.
Taman/o de uma cone0o CCC.
L
f ( 2 , o)=o
2
m
o
2
(o+;)
,
Di#!ri5uio Lo$ormal
ma vari6vel pode ser modelada como lognormal se puder ser considerada como o produto
multiplicativo de muitos pe$uenos fatores independentes. !0emplos t-picos 3 o retorno a longo pra,o
de um investimento em uma ao# pode?se considerar como o produto dos retornos di6rios. !sta
distri%uio 3 tam%3m muito utili,ada para estimativa de tempo de reparo de um processo# ou se)a# o
tempo entre ocorrer uma fal/a e o tempo para $ue ela se)a corrigida. ( funo densidade de
pro%a%ilidade da distri%uio .ognormal 3 dado por
f ( 2 3 j, c)=
;
2 c
.
=n
e
ln( 2j)
=
=c
=
,
78<
onde e so a media e o desvio padro respectivamente e 0 _ I.
Di#!ri5uio de Poi##o$
( distri%uio de Poisson 3 utili,ada para vari6veis aleatrias discretas. !la determina a
$uantidade de ocorr:ncias em um determinado intervalo de tempo. Os eventos devem ocorrer em um
certo intervalo de tempo ou espao. \ utili,ada em c/amadas telef]nicas por unidade de tempo#
acidentes por unidade de tempo# c/egada de clientes por unidade de tempo e etc. Sua funo densidade
de pro%a%ilidade 3 dada como:
p( 2 3\, t )=
(\t )
2
e
\t
2!
para 2=I#;#= ,...
7O<
onde ` 3 a ta0a m3dia do processo e t 3 o intervalo de tempo5espao.
( distri%uio possui as seguintes caracter-sticas:
O tempo de c/egada 3 e0ponencial# $ue no possui memria.
( ta0a m3dia do processo# `# deve permanecer constante durante o per-odo de tempo e espao
considerados.
Juanto menor o segmento de tempo e espao# menor a pro%a%ilidade de ocorrer mais de um
evento na$uele segmento. ( pro%a%ilidade de ocorr:ncia de = ou mais eventos tende a ,ero
$uando o taman/o do segmento tende a ,ero.
Di#!ri5uio =i:er>e9:o$e$+ial
( distri%uio Yiper?e0ponencial 3 uma distri%uio cont-nua na $ual 3 dada como:
f2 ( 2)=
n=;
n
fy
i
( 2)p
i
, 79<
onde yi 3 uma distri%uio e0ponencial. \ considerada uma distri%uio /iper?e0ponencial desde $ue
seu coeficiente se)a maior do $ue o coeficiente da distri%uio e0ponencial.
;I
m e0emplo no conte0to de telefonia onde se um usu6rio possui um modem e um telefone# a
pro%a%ilidade pi do usu6rio utili,ar o telefone ao mesmo tempo $ue o modem 3 dado por pela
distri%uio /iper?e0ponencial.
&8/ ?ualidade de Ser@io A?oS6
2a area de redes de comunica+es o termo Jualidade de Servio 7JoS< refere?se a mecanismos
de reserva de recursos. O JoS 3 uma ferramenta $ue possui diferentes prioridades as diferentes
aplica+es# para garantir um determinado n-vel de desempen/o para um flu0o de dados. Diferentes
par*metros podem ser usados para garantir o JoS# como# ta0a de %its# atraso# jitter# ta0a de erro# e etc.
&ecanismos $ue garantam a $ualidade de servio so importantes se a capacidade da rede 3
insuficiente# especialmente para aplica+es em tempo real# como v-deo stream# )6 $ue estas aplica+es
e0igem uma ta0a de %its fi0a e so sens-veis a atrasos. ( seguir veremos alguns desses mecanismos.
Va%o
!m termos pr6ticos as aplica+es geram va,+es $ue devem ser atendidas pela rede. Dessa forma o
canal deve ter uma largura de %anda m-nima para o funcionamento ade$uado para cada tipo de
aplica+es. ( ta%ela a seguir ilustra a va,o tipica de algumas aplica+es.
(plica+es Va,o Tipica
Vo, ;I E%ps a ;II E%ps
(plica+es Ce% ;I E%ps a OII E%ps
Video Streaming ;II E%ps a ; &%ps
Video &P!F ; &%ps a ;I &%ps
Ta5ela &. Va,o t-pica das aplica+es.
La!B$+ia
( lat:ncia da rede pode ser definida como o somatrio dos atrasos impostos pela rede e
e$uipamentos utili,ados no sistema de comunicao. "omo o atraso de propagao# fila# velocidade de
transmisso e processamento nos e$uipamentos.
Devido lat:ncia# o tempo $ue leva para um pacote c/egar ao seu destino pode aumentar. 'sso
por$ue e0iste congestionamentos durante o percurso de entrega do pacote. "omo por e0emplo longas
filas# ou rotas com um maior nKmero de ns.
DelaC
O delaB ocorre $uando os pacotes de servios# como de vo,# lavam mais tempo do $ue o esperado para
c/egar ao seu destino. 'sso causa degradao na $ualidade da c/amada. !ntretanto se for tratado
ade$uadamente os seus efeitos so minimi,ados# como a utili,ao de *uffers.
;;
Jitter
O jitter pode ser entendido como a variao no tempo e na se$uencia de entrega das informa+es#
ocorrendo uma distoro no processamento da informao na recepo. Para evita?lo deve?se utili,ar
mecanismos espec-ficos de compensao e controle $ue dependem da aplicao em $uesto.
Fenericamente# uma das solu+es mais comuns para o pro%lema consiste na utili,ao de *uffers.
(s aplica+es no interativas no so muito afetadas pelo )itter# por3m os usu6rios de aplicativos
$ue envolvem m-dia interativas 76udio e v-deo< como Vo, So%re 'P 7Vo'P<# e videoconfer:ncia podem
ser muito afetados pelo )itter. 'sso por$ue as aplica+es interativas utili,am codecs# $ue# para um
funcionamento correto# para garantir uma ta0a de flu0o de dados constante. Os pacotes $ue carregam
m-dias interativas so gerados em suas origens a ta0as constantes mas# ao atravessarem a rede# sofrem
retardos diferentes e c/egam ao destino no sincroni,ados.
!m principio# o pro%lema dos pacotes fora de ordem poderiam ser resolvidos com o au0ilio de
um protocolo de transporte como o T"P# $ue verifica a se$uencia das mensagens e fa, as devidas
corre+es. !ntretanto# na pratica tem?se $ue a grande maioria das aplica+es multim-dia optam por
utili,ar o DP ao inv3s do T"P pela maior simplicidade e menos overhead. 2estes casos# o pro%lema
de se$uencia deve ser resolvido por protocolos de mais alto nivel normalmente incorporados a
aplicao como# por e0emplo# o 1TP 7Real Time Transfer &rotocol<.
( definio ideal do taman/o de um *uffer para prevenir o jitter 3 muito importante para a
$ualidade da transmisso de m-dias interativo. Se o *uffer 3 pe$ueno demais pode no conseguir
a%rigar uma longa ra)ada de pacotes devido a reten+es na rede ou em um servidor de m-dia#
ocasionando perda por trans%ordo. Tam%3m por ser de taman/o insuficiente# o *uffer no ser6 capa, de
arma,enar um nKmero de pacotes necess6rio para anular o efeito do jitter caso isto acontea# o *uffer
ser6 esva,iado e a reproduo do v-deo ou 6udio sofrer6 paralisa+es dando origem aos atrasos. Se o
*uffer 3 grande demais acentua?se o pro%lema de interrupo entre sess+es interativas# ou se)a#
interrup+es entre as falas dos locutores ou entre as respostas dos participantes de uma
videoconfer:ncia.
O protocolo 1TP G1F" ;NNLH leva em conta o princ-pio %6sico de $ue um *uffer din*mico aumenta
seu taman/o $uando Zen0erga[ um aumento no jitter da rede. 2ele# o campo inter4arrival jitter prev:
uma medida de curto pra,o para o congestionamento da rede. ( finalidade dessa medida 3 indicar um
congestionamento na rede antes $ue ocorra uma perda de pacote. O protocolo 1TP utili,a diversos
algoritmos para estimar uma poss-vel mudana no taman/o do *uffer, atrav3s da verificao de todos os
campos inter4arrival jitter de um determinado receptor ao longo do tempo ou de mKltiplos receptores
de uma mesma rede!
&80 TD+$i+a# al!er$a!i@a# de ?oS
I$!Ser@ e RSVP
( t3cnica 'ntServ est6 atualmente sendo definida pelo '!TF e corresponde a um con)unto de
recomenda+es 71F" ==;;# ==;=# ==;O< visando a implantao de uma 'nfraestrutura ro%usta para a
internet $ue possa suportar o transporte de 6udio# v-deo e dados em tempo real G=O01
2a ar$uitetura 'ntServ# dois aspectos operacionais so considerados para $ue a aplicao possa
reali,ar a reserva dos recursos $ue sero utili,ados antes de iniciar o envio dos pacotes pela rede. !les
so:
;=
"omo as aplica+es solicitam sua necessidade de JoS rede.
! como os dispositivos intermedi6rios# como roteadores# devem proceder para garantir o JoS
solicitado.
( solicitao 3 reali,ada atrav3s do protocolo de sinali,ao 1SVP. 2ele a aplicao informa
$uais recursos sero necess6rios. Os dispositivos intermedi6rios da rede sero os respons6veis para
garantir a reserva solicitada. ma ve, aceita a reserva# os flu0os de dados correspondentes a aplicao
so identificados e roteados.
DiffSer@
O DiffServ usa mecanismos de marcao de pacotes# verificao local da classe dos pacotes# e
gerenciamento de recursos para suportar diferentes n-veis de servios em uma rede 'P. Seguindo G=OH#
sua terminologia 3 a seguinte:
&er4hop *ehavior 7PYP<: Todos os pacotes devem sofrer a mesma analise durante um salto#
enfileiramento e descarte# caso os recursos no satisfaam o servio.
(ifferentiated services code point 7DS"P<: \ um valor no ca%eal/o 'P $ue indica $ue o pacote
em $uesto sofrer6 a analise PYP.
Os DS"Ps no ca%eal/o do pacote indicam como os pacotes devem ser tratados nos saltos entre
os roteadores intermedi6rios at3 $ue o pacote c/egue ao seu destino. O DS"P esta presente no
ca%eal/o do protocolo 'Pv8 no campo Type of Service 7ToS< e no protocolo 'Pv9 no campo Traffic
Class. Seis %its# dos N %its de um %Bte do ToS# so alocados para o DS"P# e os outros dois %its so
alocados para a 2plicit Con,estion "otification 7!"2<. O comportamento dos saltos do DiffServ
podem ser definidos da seguinte forma:
&el/or esforo.
Pai0o atraso# lat:ncia# e jitter.
O Diffserv foi desenvolvido pensando em ser mais simples e escal6vel do $ue o 'ntServ51SVP#
por$ue no re$uer sinali,ao ou flu0o na rede. Todas as aplica+es podem utili,a?lo sem precisar
reali,ar nen/um tipo de mudana nos roteadores. O meio de transporte utili,ado para o DiffeServ pode
ser tanto 'P $uanto (T&# Frame 1elaB# &P.S# ou uma com%inao po$ue esses e0emplos de
protocolos de transporte esto em um n-vel acima da camada de rede. (ssim sendo# os roteadores
analisam apenas a camada de rede para $ue possam desco%rir $ual 3 o host de destino dos pacotes para
encamin/a?los. Diferentes manipula+es de pacotes e mapeamento so poss-veis por e0emplo# o
indicador da classe de servio pode representar prioridades de congestionamento de flu0o onde pacotes
com %ai0a prioridade so descartados primeiro.
Poli!i+a de +o$!role de admi##o de +Eamada#8
De acordo com as necessidades pr6ticas e especifica+es do >FPP# as prioridades para tr6fego
multim-dia so descritos na Ta%. O G=>H.
;>
"lasse Definio >FPP Prioridade "lasse de tr6fego
;
=
>
8
"onversao
Streamin,
'nteratividade
5ack,round
(lta
&3dia
Pai0a
&ais Pai0a
Vo,
V-deo
'nternet
!?mail
Ta5ela /. Prioridades para tr6fego multim-dia.
Os tr6fegos de vo, e v-deo so sens-veis ao atraso e os pacotes de vo, no podem ser
retransmitidos $uando ocorre uma fal/a. 2o caso do v-deo# pode?se perder alguns %its menos
significativos $uando o recursos so insuficientes. 2ormalmente# os pacotes podem tolerar algum
atraso# especialmente os de dados $ue so do tipo el6stico# podendo tolerar mais atrasos do $ue os do
tipo stream. 2o caso de stream# se o sistema estiver so%recarregado 3 recomendado o %lo$ueio do
pacote ao inv3s de coloc6?lo em um *uffer# pois a sesso pode ser refeita novamente aps ser
%lo$ueada.
"omo indicado na Ta%. O# as classes dos tr6fegos descrevem diferentes tipos de comportamento#
com isso# teremos diferentes JoS $ue significam prioridades diferentes. Por e0emplo# a pro%a%ilidade
de %lo$ueio 3 um crit3rio importante para JoS para vo,# mas no c/ega a ser tao importante como para
dados# pois ele pode suportar atrasos. (s classes com prioridades mais altas t:m privil3gio so%re as
classes com prioridades mais %ai0as no processo de "(". ( JoS das classes de prioridades mais altas
devem ser processadas antes $ue as outras# certos privil3gios devem ser reservados# como a retirada de
uma parte dos recursos destinados s classes mais %ai0as $uando os recursos do sistema estiver
inade$uado. Suprindo a ta0a de tr6fego necess6ria para seu funcionamento correto. (ssim# a JoS da
classe de tr6fego poder6 ser garantida.
Pasicamente# a politica do "(" 3 %aseada na estimativa da capacidade do recursos reservados e
no reservados. ( pol-tica de reserva 3 mostrada na Fig. L. ( capacidade total 3 considerada como
sendo igual a ;# ento de acordo com re$uisitos de JoS e as definio de prioridades# a capacidade
m60ima pode ser usada por vo,# v-deo# internet e de e?mail so: ;# 7;cc<# 7;c%<# 7;ca<, respectivamente#
onde a# %# c so dinamicamente a)ustados com %ase na demanda do sistema e na medio da carga de
tr6fego# e a ^ % ^ c. Portanto# os limites da capacidade no reservada para vo,# v-deo# internet e de e?
mail so de I# cd# %d# e ad# respectivamente. Juando c/ega uma c/amada de vo,# a capacidade da
%anda no reservada 3 estimada se)a superior ao limiar ou no. Se assim for# a c/amada 3 admitida#
caso contr6rio# pode privar uma parte do recurso alocado para as classes de menor prioridade de
tr6fego# como v-deo# internet ou de e?mail# $ue ten/am sido admitidos. O processo de privao 3 o
seguinte: os tr6fegos de e?mail so postos de lado# e colocados em um *uffer. !nto# fa,?se a estiva da
capacidade dispon-vel novamente. Se for mais do $ue o limite# o pedido de vo, poderia ser admitido#
caso contr6rio# o tr6fego de internet $ue est6 no canal 3 %lo$ueado# e da capacidade dispon-vel fa,?se a
estimativa novamente. Se a capacidade dispon-vel ainda 3 inferior ao limiar# a $ualidade de transmisso
do tr6fego de v-deo ser6 degradada para li%erar uma parte dos recursos alocados. O pedido de vo, ser6
admitido se o recurso residual 3 ade$uado# caso contr6rio# ser6 re)eitado.
;8
Fiura 1. 1eservas dos servios.
&81 Modelo A$al"!i+o
Paseado na refer:ncia G=NH# o dimensionamento do tr6fego 3 reali,ado por dois modelos
independentes# um para o tr6fego el6stico e um outro para o stream. (ssim a capacidade total do canal
3 dividida em dois# uma parte 3 dedicada ao tr6fego el6stico e a outra ao tr6fego stream. Por e0emplo#
" a "s e "e a 8 &%it5s# onde " 3 a capacidade total do canal# "s 3 a poro stream# e "e a poro
el6stica. O modelo ana-tico a$ui apresentado 3 utili,ado nos modelos de simula+es = e >.
&818( Dime$#io$ame$!o do Trfeo El#!i+o
"omo o servio de Dados 3 o Knico tr6fego el6stico presente no nosso modelo# assumimos $ue
o valor da %anda "e igual a ;=N A%it5s 3 suficiente. !m um caso ideal# o canal $ue transmite o
protocolo T"P# tr6fego el6stico# pode ser representado como um sistema Processor S/aring 7PS< no
$ual todos os flu0os ativos compartil/am os recursos dispon-veis igualmente G=LH. (l3m disso# o canal
pode ser modelado como uma fila &5F51 PS# onde o processo de c/egada 3 &arAoviano 7&< ou
e0ponencial e a distri%uio de durao do servio 3 general 7F<. 2o nosso caso utili,amos a
distri%uio e0ponencial com 1a=# $ue e$uivale a uma %anda "e a 980= a ;=N A%it5s 7assumindo a
menor $uantidade de %anda dispon-vel 3 98 A%it5s<. Para estimar o tempo de espera para o tratamento
deste tr6fego# 3 utili,ado a distri%uio de espera !rlang "# dada por

=

+
=
;
I
=
f f
f
< # 7
R
i
R i
R
R
R
R i
R
R
R
R
# 7M<
onde j denomina o tr6fego gerado pelo servio de Dados# no $ual 3 igual a ;I0I.I>O a I.>O !rl 7Ta%.
M< $ue fornece uma pro%a%ilidade esperada de != 7=# I.>O< a I.IO=;>.
Para o modelo &5F51 PS# o tempo m3dio para transferir um ar$uivo de taman/o 2 3 dado por
;O

[ ] s ;M . I
< # 7
; < 7
=
=
+ =
R
R
h
2
2 T
e
# 7N<
onde 0 a N8 A%Btes 7Ta%. M< e supondo $ue a ta0a de transfer:ncia de uma cone0o no 3 limitada# a
ta0a de pico 3 a largura de %anda do canal# he a 8 &%it5s por$ue a e0ig:ncia 3 de $ue ;II A%Btes se)a
transferidos em ;O segundos# o $ue implica em N8A%Btes se)a transferidos em ;=#9 segundos# portanto o
tempo de perman:ncia 3 muito %ai0o comparado com o desempen/o. "omo visto# os re$uerimentos
para um JoS foi satisfeito com "e a ;=N A%it5s.
&818& Dime$#io$ame$!o do Trfeo Stream
( capacidade total do canal 3 de 8 &%it5s# sendo $ue ;=N A%it5s foram alocados para tr6fegos
el6sticos# ento# /aver6 uma capacidade dispon-vel de >NM= A%it5s para o tr6fego stream. Para cada
solicitao de servio i# a constante da ta0a de %it ci 3 reservada# e aps sua re$uisio# ela 3 li%erada
imediatamente. ( soluo geral na forma de produto pode ser escrito como
#
;
f
< #...# # 7
;
= ;
=
=
"
i i
n
i
"
% n
n n n p
i
7L<
onde % 3 a constante de normali,ao. ( pro%a%ilidade de %lo$ueio do servio i para suportar o tr6fego
j
i
3 denotado por *i# e pode ser calculado pelo m3todo apro0imado de .a%ourdette G>IH dado por

d
C
d
/
/
C
*
s
s
c
i
i
#
;
;
# 7;I<
onde "s 3 o canal reservado para o tr6fego stream e

=
=
m
i
i i
c /
;
# 7;;<
onde / 3 o tr6fego total oferecido# m 3 o nKmero de tipos de elementos de rede# pi e ci so#
respectivamente# a intensidade do servio i e %anda efetiva. Todos os servios stream tem uma largura
de %anda efetiva de >= A%it5s# $ue 3 o valor do codec utili,ado

I ;
;
=
=
i
C
m
i
s
i i
C
c
# 7;=<
onde : par*metro $ue satisfa, a e$uao#

log
log
/
C
d
S
=
# 7;><
onde d: largura de %anda do sistema e$uivalente#

( )
( )
d
/
i
i
S
d
/
S
S
i
d
C
d
C
d
/
d
C
I
;
f
#
# 7;8<
denota a formula de %lo$ueio de !rlang P para um nKmero fracion6rio de troncos 7servidores<#
e0igindo um procedimento num3rica espec-fico para a sua resoluo.
;9
Sendo Cs a >NM= A%it5s# maO# com valores de
j
i
da Ta%. M# o%temos = ;.IIIIIM;I=99, /a
>IN8NII %it5s# da >=III %its 7so todos iguais os codec dos servios< o%temos

>
;I . = #

=
d
/
d
C
s
. 7;O<
Portanto# os valores de %lo$ueio *
;
=0;I
?>
7todos os servios stream<# satisfa,endo os re$uisitos de
JoS estipulados.
;M
/8 Gerador de Trfeo Mul!im"dia
m gerador de tr6fego multim-dia 3 um gerador de tr6fego associado a servios multim-dia#
como 6udio# v-deo# vo,# e dados. Para se gerar um padro de tr6fego# &P!F?8 por e0emplo# de modo
semel/ante aos vistos em um cen6rio real# utili,am?se fun+es de distri%ui+es $ue mel/or representam
o seu comportamento. Dessa forma# para $ue um gerador de tr6fego se)a o mais fiel poss-vel a tr6fegos
reais# 3 necess6rio a utili,ao de diferentes tipos de distri%ui+es para cada tipo de servio.
O gerador multim-dia originalmente foi feito utili,ando?se um 5erkeley sockets 2mais
con/ecido como PSD socAet (P'3, e foi desenvolvido por (gugliari e Oliveira G=IH. O socket foi
utili,ado# em princ-pio# para facilitar a implementao# pois em um primeiro momento foi importante a
verificao dos perfis de tr6fego. ( incorporao da pil/a T"P5'P ao gerador 3 essencial para se ter
controle dos ca%eal/os do pacote 'P $ue so respons6veis por determinar o tipo de servio. 2o
"apitulo 8 discutiremos a pil/a T"P5'P $ue su%stituir6 o socket.
O gerador de tr6fego multim-dia 3 composto por dois su%sistemas: o gerador# $ue gera os
pacotes de acordo com o perfil dese)ado para cada serviog e o receptor# $ue est6 presente em outro
elemento da rede e rece%e os pacotes e arma,ena as informa+es so%re o tr6fego. Para as simula+es#
foi utili,ada inicialmente apenas a distri%uio e0ponencial# tanto para intervalo de c/egada $uanto
para taman/o5durao dos servios# por ser a mais utili,ada $uando se dese)a analisar o espao ou
intervalo de acontecimento de um evento.
O gerador de tr6fego multim-dia consiste dos seguintes principais mdulos:
Sele!or de Ser@io: "ont3m as informa+es de cada servio. (rma,ena os dados respons6veis pela
criao de um novo servio em um tempo determinado# al3m garanti o in-cio do funcionamento da
m6$uina de estado. "ada servio tem um comportamento pr3?definido e um momento certo para $ue
se)a iniciado. 'sso 3 verificado atrav3s de uma distri%uio de pro%a%ilidade $ue represente o
comportamento da rede. 2o entanto# para $ue um servio se)a iniciado# dever6 antes ser verificado o
controle de admisso de cada servio# $ue 3 re$uisito da rede simulada# ou se)a# o nKmero m60imo de
servios simult*neos suportados pela rede.
Perfilador de Trfeo: "ont3m as informa+es so%re o tipo de tr6fego $ue vai ser gerado para cada
servio. !sse mdulo por sua ve, ir6 influenciar na gerao dos pacotes# indicando a periodicidade e o
taman/o com $ue eles devem ser criados. Tendo identificado as caracter-sticas de um novo servio# 3
necess6rio# atrav3s do perfil de tr6fego# identificar a durao do servio 7no caso de vo,# 6udio e v-deo<#
ou o taman/o dos pacotes 7no caso de dados<# cu)os par*metros variam a cada novo servio. !les
tam%3m devem seguir uma distri%uio de pro%a%ilidade.
Gerador de Pa+o!e: Fera os pacotes para cada servio. Os pacotes devero ser identificados no
Ferador e no 1eceptor# pois contem as informa+es de cada servio. "omo os dados gerados so
aleatrios# e a fim de se o%ter dados para montagem da estat-stica final dos pacotes# ao inv3s de enviar
pacotes sem significado# so enviados no conteKdo os dados relacionados a seguir:
;N
Tipo do servio 7vo,# v-deo# 6udio ou dados<.
'dentificao do servio 7para numerao dos servios de acordo com cada tipo<.
2Kmero do pacote 7para contagem final dos pacotes de cada servio e verificao de perdas<.
Tempo de gerao do servio 7momento em $ue o servio foi gerado<.
Tempo de durao total do Servio Vo,# V-deo e Tudio ou taman/o total do servio para Dados.
Tempo de gerao do pacote e tempo do pacote entrar na fila.
Tempo $ue leva para o Socket enviar o pacote.
Pits de preenc/imento 7para completar o taman/o do pacote# se necess6rio<.
(ps cada pacote ser gerado contendo as informa+es listadas anteriormente# ele 3 enviado para
a rede via socket. !le foi utili,ado# em princ-pio# para facilitar a implementao# pois neste primeiro
momento 3 importante verificar os perfis de tr6fego. Para tra%al/os futuros# a su%stituio do socket
pela pil/a T"P5'P 3 essencial# proporcionando controle do ca%eal/o do protocolo 'P# como os
seguintes headers6 Type of Service, Tcflo., e Traffic Class# $ue sero utili,ados para separar os pacotes
de acordo com o servio.
Fiura 2. 1epresentao es$uem6tica da &6$uina de !stado do Ferador.
Para a e0ecuo em paralelo da gerao dos $uatro servios e do tratamento e envio dos pacotes
foi utili,ado o conceito de T/read. !la est6 presente nos seguintes pontos:
"iclo principal Servio Tr6fego Pacote.
Tratamento de gerao individual de pacotes# aps ser definido o perfil do tr6fego.
Para $ue sua implementao fosse comum a v6rios sistemas operacionais foram utili,adas a
linguagem "ee e o padro POS'Q T/reads# atrav3s da %i%lioteca pt/read./. O padro define uma (P'
para criar e manipular T/reads em sistemas %aseados em 2'Q# como F25.inu0# &ac OS Q e
SO.(1'S. Sua utili,ao tam%3m 3 poss-vel no sistema operacional Cindo@s# atrav3s da (P' pt/read?
@>= $ue tradu, as instru+es de T/read para $ue possam ser interpretadas nas plataformas >=?%its do
Cindo@s.
O modelo ar$uitetural de T/reads segue o padro con/ecido em Xava# $ue pode ser atrav3s da
criao de uma nova classe T/read ou atrav3s da implementao de 1unna%le. !ste conceito foi
retirado de G=;H $ue cont3m uma implementao padro de classes para POS'Q T/reads.
;L
!eletor de
!ervi"os
Perfilador
de Trfego
4erador de
Pacotes
!oc5et
Inicio
/8( De#+rio do# Pro!o+olo# de Tra$#:or!e
Pro!o+olo TCP ATransmission Control Protocol6
O protocolo T"P# formalmente definido na 1F" ML># tem como principal caracter-stica oferecer
um flu0o confi6vel de dados fim a fim. ma rede pode no ser confi6vel devido a v6rios fatores como
topologia# largura de %anda# retardo# taman/os de pacote entre outros# $ue so completamente
diferentes umas das outras. !le foi pro)etado para se adaptar a diferentes aspectos de rede e ser ro%usto
diante dos fatores de fal/a. O ca%eal/o T"P cont3m =I %Btes $ue so detal/ados a seguir:
Fiura 3. Segmento T"P G=8H.
- Source / Destination port: 2Kmero 'P e porta T"P endeream um destino Knico ou um destino para a
entrega de um segmento. O 'P determina o host e a porta determina a aplicao $ue tem a%erto a porta.
m socket deve ser utili,ado para mKltiplas e simult*neas cone0+es.
- Sequence/ Acknowledgement number: !numera cada %Bte para fragmentao e reconstruo.
- TCP header length: 2Kmero com palavra de >= %its do ca%eal/o T"P
- Flags: 1F c Sinali,a dado urgente do -r,ent &ointer
("E c Sinali,a $ue nKmero de Akcno.led,ements 3 v6lido
PSY c !sse tipo de dado deve ser enviado imediatamente sem *uffer adicional por ra,+es de
efici:ncia
1ST c .impa a cone0o
Sh2 c sado no esta%elecimento de cone0o
F'2 c .i%era canal de comunicao
=I
- indow si!e: Para controle de flu0o ponto a ponto. "ont3m o nKmero de octetos $ue o receptor est6
pronto para aceitar. ma )anela T"P 3 a $uantidade de dados no confirmados pelo receptor $ue um
remetente pode enviar atrav3s de uma cone0o antes de rece%er uma confirmao de rece%imento do
destinat6rio.
- Checksum: 'nformao usada para c/ecar o ca%eal/o# dados# e pseudo ca%eal/o para
confia%ilidade. O receptor adiciona todos os ;9 %its rece%idos incluindo o checksum# e o resultado deve
ser I se os campos do checksum estiverem de acordo.
- "ptions: ma opo 3 o m60imo taman/o do payload do T"P $ue o host ir6 aceitar. O padro 3 OO9
%Btes. \ um fator de aumento de escala da )anela de recepo para redes de alta velocidade. !le 3
utili,ado na negociao do &SS 7/a2imum Se,ment Si7e<.
Pro!o+olo UDP A#ser Datagram Protocol6
O DP# ao contr6rio do T"P# oferece um meio para transmisso sem $ue /a)a a necessidade de
cone0o. !le 3 descrito na 1F" M9N e no reali,a : "ontrole de Flu0o# "ontrole de !rros#
1etransmisso aps recepo de um segmento incorreto. O segmento DP consiste de um pe$ueno
ca%eal/o de N %Btes# como pode ser visto na figura a seguir.
Fiura ). Datagrama DP G=8H.
- Source Port: sada $uando uma resposta deve ser devolvida a origem
- Destination Port: 'ndica $ual a porta de comunicao do destino
- #DP $ength: 'nclui o ca%eal/o de N %Btes e os dados# indicando o taman/o do segmento
- #DP Checskum: "ampo opcional para controle de erro.
!le apenas fornece uma interface para o protocolo 'P com o recurso adicional de
demultiple0ao de v6rios processos $ue utili,am as portas. \ Ktil para processos cliente?servidor# onde
o cliente envia uma pe$uena solicitao ao servidor e espera uma resposta. "aso ocorra um timeout, o
cliente tenta novamente por3m sem e0istir inKmeras trocas de mensagem como no T"P. O DP 3 uma
escol/a ade$uada para:
Flu0os de dados em tempo real $ue suporta perda limitada de pacotes# como v-deos ou vo,.
(plica+es sens-veis a atrasos na rede# mas pouco sens-veis a perdas.
O protocolo T"P envolve retransmiss+es e espera de dados# tra,endo como conse$u:ncia uma
alta lat:ncia.
=;
/8& Re#ul!ado# NumDri+o#
(s simula+es foram inicialmente feitas utili,ando?se o gerador de tr6fego e o soft@are de
simulao de eventos discretos de propsito geral (1!2( G;N# =>H. O gerador de tr6fego permite um
n-vel maior de detal/es de transmisso e mais pr0imo da realidade 7como ta0a de um codec# taman/o
do pacote# transmisso pelo canal e pro%lemas $ue podem ocorrer durante uma transmisso como
$ueda de cone0o<# e o soft@are (1!2( permite uma simulao com a%strao dos pacotes#
a%straindo detal/es de transmisso e preocupando?se mais com as caracter-sticas de gerao e
disponi%ilidade de cada servio.
O gerador de tr6fego permite conviver com um am%iente mais pr0imo do real. 2o entanto#
pelo fato dele reali,ar uma emulao em tempo real# se sua durao for de ;I /oras# ele ter6 $ue ser
e0ecutado durante ;I /oras.
X6 o simulador por eventos discretos# pelo fato de tra%al/ar com as caracter-sticas mais
importantes dos eventos $ue ocorrem na rede# pode fa,er a mesma rodada de ;I /oras de simulao em
apenas alguns minutos. 2a verdade a simulao sera a mais simples poss-vel# de modo $ue consiga
refletir os principais pro%lemas de conteno das filas $ue certamente se formaro na rede devido a
perdas5atrasos.
Os resultados das simula+es do (1!2( e do Ferador de tr6fego foram %em pr0imos. !m
relao re)eio de servios stream devido ao controle de admisso# tam%3m foram o%tidos dados
coerentes se compararmos com as simula+es reali,adas. (penas em um servio de v-deo ocorreu fal/a
nas simula+es do gerador de tr6fego# contra ,ero do simulador (1!2(. !ssa perda provavelmente
ocorreu devido gerao aleatria# $ue iniciou um servio antes dos outros serem finali,ados. (s
outras perdas tam%3m ficaram em ,ero# indicando $ue o sistema est6 %em dimensionado para atender
ao tr6fego feito na simulao.
'nicialmente as simula+es do (1!2( e a emulao do Ferador de Tr6fego &ultim-dia foram
reali,adas utili,ando uma distri%uio e0ponencial com os mesmos par*metros. O fato de se utili,ar
apenas as distri%ui+es e0ponencial inicialmente foi para facilitar a sua cali%rao. 2a refer:ncia G>MH
tam%3m /6 detal/es so%re a emulao# simulao e resultados o%tidos.
.argura de %anda total dispon-vel: 8 &%ps
Tempo total: ;I /oras
Vo'P
.iga+es com durao m3dia de ;NI s 7 > min<
Tempo m3dio entre re$uisi+es de servio de >9 s 7;II c/amadas por /ora em m3dia<
&60imo de MI c/amadas simult*neas 7controle de admisso<
"OD!" de ;9 A%ps
Tudio
Sess+es com durao m3dia de OII s 7iN min<
Tempo m3dio entre re$uisi+es de servio de >9I s 7;I c/amadas por /ora em m3dia<
&60imo de ;I sess+es simult*neas 7controle de admisso<
"OD!" de =I A%ps
==
V-deoconfer:ncia
Sess+es com durao m3dia de LII s 7;O min<
Tempo m3dio entre re$uisi+es de servio de >9II s 7; c/amada por /ora em m3dia<
&60imo de = sess+es simult*neas 7controle de admisso<
"OD!" de >= A%ps
Os resultados o%tidos no (1!2( e no Ferador de Tr6fego &ultim-dia esto apresentados nas
Ta%. 8 e O. Podemos o%servar $ue os valores so %em compat-veis. 2ote $ue o (1!2( simula ;I /oras
de servio em %em menos tempo 7apro0imadamente ;I minutos<# en$uanto o gerador e0ecuta o tempo
total 7;I /oras<.
2a emulao foi utili,ado dois computadores (pple# um como transmissor e o outro como
receptor. O transmissor 3 um i&ac 'ntel "ore = Duo =.=F/,# e o receptor um &ac mini com um
Po@erP" F8 de ; F/,. 2a simulao foi utili,ado um note%ooA YP (&D Turion Q= 98 =.I F/,.
(parentemente# as diferenas o%servadas devem?se a fatores aleatrios intr-nsecos ao modelo
estat-stico. Dependem tam%3m do intervalo de gerao e das caracter-sticas do emulador 7o $ue no
ocorre no caso da simulao<.
Ser@io MDdia A#6 M"$imo A#6 M9imo A#6 ?ua$!idade
Vo'P ;9L#>O I#89 ;;ML ;I=>
Tudio 8L9#MO ;>#L =N8O ;;I
V-deoconfer:ncia ;IM; O;#99 8>9; ;=
Ta5ela 0. "aracter-sticas dos servios gerados na simulao do (rena.
Ser@io M"$imo A#6 M9imo A#6 ?ua$!idade
Vo'P ;N 9O9 ;IIL
Tudio L> =M>9 NM
V-deoconfer:ncia 8L >=NM ;L
Ta5ela 1. "aracter-sticas dos servios gerados na emulao do Ferador de Tr6fego &ultim-dia.
=>
08 PilEa TCP*IP
2este capitulo 3 descrito o comportamento da pil/a u'P 7T"P5'P< $ue# a princ-pio# ir6 su%stituir
o socket do gerador descrito no capitulo >. O u'P foi desenvolvido inicialmente por (dam DunAels do
grupo "et.orked m*edded Systems no S.edish Institute of Computer Science G==H! (l3m dele# o u'P
teve contri%ui+es de diversos desenvolvedores de soft@are de todas as partes do mundo. 2s a
escol/emos por$ue 3 uma pil/a %aseada em ni0 e de cdigo a%erto# possi%ilitando a sua adaptao de
forma a alcanar o nosso proposito# $ue 3 a su%stituio do socket pela pil/a T"P5'P# afim de termos
controle do ca%eal/o 'P .
( implementao do u'P G=IH foi feita para possuir apenas os re$uisitos m-nimos necess6rios
para o funcionamento ade$uado da pil/a T"P5'P# proporcionando uma interface de rede simples $ue
contem os protocolos 'P# '"&P#DP e T"P.
( pil/a u'P foi criada para a possi%ilidade de reali,ar comunicao utili,ando o protocolo
T"P5'P em at3 mesmo microcontroladores de N?%its. O taman/o do cdigo 3 de apenas alguns Ailo%Btes
e a 1(& utili,ada pode ser configura da para ser menor $ue algumas centenas de %Btes.
08( O uIP
( pil/a u'P pode ser e0ecutada tanto como um sistema multitarefas# ou como monotarefa. 2os
dois casos# o lao principal reali,a duas a+es repetidamente:
"/eca se algum pacote c/egou.
"/eca se o tempo de sa-da peridico foi e0cedido.

Juando um pacote c/ega# a funo de entrada uip8input9) 3 c/amada pelo lao principal. 2ela
so feitos diversas verifica+es# como a do header para desco%rir $ual tipo de servio e canal pertence
a$uele pacote para ento notificar a devia aplicao# verifica se a largura do pacote 3 ade$uada ao
taman/o do *uffer# e configura diversas constantes e ponteiros para $ue a pr0imo lao os identifi$ue.
(l3m disso 3 feito a verificao de erros nos pacotes utili,ando o checksum!
O timer peridico de sa-da 3 utili,ado em mecanismos do T"P# tais como o delayed
ackno.led,ment# retransmisso e o tempo de round4trip 7ida e volta<. Juando o lao principal infere
$ue o timer peridico deve disparar# deve?se c/amar a funo de manipulao do timer peridico#
uip8periodic9). "om isso# a pil/a T"P5'P pode reali,ar uma retransmisso do pacote $uando ocorre um
atraso $ue e0cede a tempori,ao de resposta de algum evento reali,ado.
=8
Fiura 4. .ao principal de c/ecagem de pacotes.
Co$!role de Mem,ria
( pil/a u'P no usa alocao de memria din*mica de forma e0pl-cita. !m ve, disso# usa um
*uffer glo%al para guardar os pacotes# e possui uma ta%ela fi0a para guardar os estados das cone0+es.
!sse *uffer 3 grande o suficiente para conter um pacote com o seu taman/o m60imo. Juando um
pacote c/ega# o driver do dispositivo o guarda no *uffer. Se o *uffer contem dados# o T"P5'P ir6
notificar a aplicao correspondente imediatamente para desocupar o *uffer o mais r6pido poss-vel.
Dessa forma# o *uffer estar6 sempre livre para os pr0imos pacotes de dados $ue c/egaro. "om isso# a
aplicao ter6 $ue processar rapidamente os dados $ue esto no *uffer ou coloc6?los em um *uffer
secund6rio para ser processado futuramente. Os pacotes no *uffer no sero apagados ou so%repostos
pelos novos pacotes rece%idos antes $ue a aplicao os ten/a processado. (ssim# os pacotes so postos
em uma fila pelo dispositivo de rede caso os dados no %uffer ainda no ten/am sido processados. Se a
fila estiver c/eia# os pacotes de c/egada sero perdidos. 'sso por$ue o u'P utili,a uma )anela de entrada
muito pe$uena# significando $ue /aver6 apenas um segmento T"P por cone0o.
2o u'P# o mesmo *uffer glo%al $ue 3 usado para os pacotes rece%idos 3 tam%3m usado para os
pacotes $ue sero transmitidos. Se a aplicao transmite dados de taman/os aleatrios# pode?se utili,ar
parte do *uffer glo%al $ue no esta sendo utili,ado como um *uffer tempor6rio. Para enviar os dados a
=O
Checa por Pacote
Checa o timer
de sa)da
Processa o
Pacote
E'ecuta a
%plica"$o
!a)da do Pacote
Processa o
Pacote
E'ecuta a
%plica"$o
!a)da do Pacote
pil/a# o aplicativo passa a apontar para os dados# %em como para a vari6vel len $ue indica o seu
comprimento. O ca%eal/o T"P5'P 3 escrito dentro do *uffer glo%al. Juando esto prontos para serem
enviados o driver os envia )untamente com os dados da aplicao para a rede. Os dados no ficam em
fila para retransmisso. !m ve, disso# a aplicao ir6 ter $ue reprodu,ir o dado se a retransmisso for
necess6ria.
( capacidade m60ima de uso de memria depende fortemente das aplica+es do dispositivo em
$ue as implementa+es so e0ecutadas. ( configurao de memria determina a $uantidade de tr6fego
$ue o sistema deve ser capa, de lidar e os montantes m60imos de cone0+es simult*neas. m
dispositivo $ue envia e?mails grandes# en$uanto ao mesmo tempo# e0ecuta um servidor @e% com
p6ginas @e% de taman/os aleatrios e v6rios clientes simult*neos# por e0emplo# e0igir6 mais memria
1(& e capacidade de processamento do $ue um simples servidor Telnet.
Application Program %nter&ace AAPI6
O (P' define como o programa de interface da aplicao interage com a pil/a T"P5'P. O (P'
mais utili,ado para pil/as T"P5'P 3 o socket PSD# $ue 3 utili,ado em sistemas ni0# e tem influenciado
muito o CinsocA (P' da &icrosoft. "omo o socket (P' usa a sinta0e stop4and4.ait# re$uer um suporte
de multitarefa do sistema operacional. O u'P prov: dois (P's para se tra%al/ar: protosocket# um socket
PSD como o (P' sem o overhead do multi4threadin,# e um (P' de mais %ai0o n-vel $ue o protosocket#
%aseado em eventos.
O protosocket prov: uma programao se$uencial de interface para facilitar a programao do
u'P. (dicionando um pe$ueno aumento na memria# ;III %Btes no cdigo e =9 %Btes e0tras por
cone0o T"P e apenas funciona para cone0+es T"P. !les utili,am protothread para fornecer controle
de flu0o se$uenciais. 'sso fa, com $ue a memria fi$ue mais leve# mas tam%3m significa $ue o
protosocket /erda as limita+es funcionais do protothread. O protosocket possui fun+es de
transmisso sem $ue /a)a a necessidade de retransmiss+es ou ackno.led,ment# %em como as fun+es
de leitura de dados sem ter $ue lidar com os dados sendo divididos em mais de um segmento T"P.
API -a#eado em E@e$!o#
O (P' %aseado em eventos do u'P usa uma interface %aseada em eventos# onde a aplicao 3
c/amada em resposta de certos eventos# como o rece%imento de um pacote. ma aplicao acima do
u'P 3 implementada como uma funo em " $ue 3 c/amada pelo u'P em resposta a determinados
eventos. O u'P c/ama a aplicao $uando um dado 3 rece%ido# $uando um dado foi entregue ao outro
ponto da cone0o com sucesso# $uando uma nova cone0o foi configurada# ou $uando um dado foi
retransmitido. ( aplicao 3 tam%3m periodicamente consultada para verificar se dese)a enviar novos
dados. ( aplicao prove apenas uma funo call*ack e respons6vel por lidar com os diferentes
mapeamentos de servios da rede para diferentes portas e cone0+es. ( aplicao atua nos dados de
c/egada e nas re$uisi+es de cone0+es# assim $ue a pil/a T"P5'P rece%er um pacote.
O u'P 3 diferente das outras pil/as T"P5'P por$ue re$uer o au0-lio da aplicao para a
reali,ao de retransmisso. !m outras pil/as T"P5'P o dado transmitido permanece na memria at3
$ue se sai%a $ue foi transmitido com sucesso. Se o dado precisa ser retransmitido# a prpria pil/a cuida
dessa retransmisso sem precisar notificar a aplicao. "om essa a%ordagem# 3 necess6rio $ue os dados
permaneam na memria esperando pelo ackno.led,ment mesmo se a aplicao este)a pronta para
reconstruir o dado se a retransmisso tiver $ue ser feita.
=9
2o u'P utili,a?se a ideia de $ue a aplicao sempre est6 pronta para a recuperao do dado
transmitido caso /a)a uma perda# com isso# 3 a aplicao a respons6vel por recriar o pacote para fa,er a
retransmisso. O u'P no mant3m o camin/o do conteKdo do pacote depois de ter sido transmitido pelo
driver# e re$uer $ue a aplicao faa um papel ativo na parte de retransmisso. Juando o u'P decide
$ue um segmento deve ser retransmitido# ele c/ama a aplicao com um fla, indicando uma
retransmisso. O aplicativo c/eca o fla, e produ, o mesmo dado $ue foi transmitido anteriormente. Do
ponto de vista da aplicao# a reali,ao de uma retransmisso no difere de como o dado original foi
transmitido. Portanto# a aplicao pode ser escrita de tal forma $ue o mesmo cdigo 3 usado tanto para
o envio de dados como para retransmisso de dados. (l3m disso# 3 importante notar $ue# mesmo $ue a
operao de retransmisso se)a reali,ada envolvendo a aplicao# 3 responsa%ilidade da pil/a sa%er
$uando uma retransmisso deve ser feita. (ssim# a comple0idade da aplicao no aumenta
necessariamente por$ue reali,a uma parte ativa fa,endo a retransmisso.
Po$!eiro da Co$e9o
Para uma mel/or compreenso de como funciona o u'P# iremos detal/ar alguns processos de
maior import*ncia. Juando a aplicao 3 c/amada pelo u'P# uma vari6vel glo%al uip8conn 3
configurada para apontar para a estrutura de cone0o. Os campos da estrutura uip8conn podem ser
utili,ados para distinguir entre diferentes servios# ou para c/ecar para $ual endereo 'P a cone0o 3
re$uisitada. m uso t-pico seria inspecionar o valor lport do uip8conn 7 lport 3 o campo $ue contem a
porta local do T"P < para decidir $ual servio a cone0o deveria prover. Por e0emplo# um aplicativo
pode decidir a agir como um servidor YTTP se o valor do lport do uip8conn 3 igual a NI e agir como
um servidor Telnet se o valor 3 =>.
CEeada de Dado#
Juando novos dados c/egam# eles so arma,enados no *uffer. Dessa forma# os conteKdos
antigos sero su%stitu-dos e os novos sero atri%u-dos aplicao correspondente atrav3s do ponteiro
uip8appdata. O uip8appdata 3 um ponteiro $ue aponta para os dados da aplicao $ue est6 no *uffer.
!la 3 c/amada $uando rece%e ou envia dados.
(l3m disso# um valor diferente de ,ero ser6 passado funo de teste uip8ne.data, indicando
$ue novos dados c/egaram. O taman/o do dado 3 o%tido atrav3s da funo uip8datalen e mantido na
vari6vel uip8len, para poder informar a aplicao o seu taman/o.

Fiura ('. Diagrama de %locos dos processos de transmisso de dados ao rece%er de um novo pacote.

=M
Esta/elece
cone'$o
6uve
uip7listen uip7conn
Error/
a/ort
uip7a/ort
Estado de
Transfer8ncia
Close
uip7input uip7close
Pasicamente# o processo de transmisso de dados ao rece%er um novo pacote 3 dado pelas
fun+es da Fig.;I. ( funo uip8listen reali,a um loop de c/ecagem constante para verificar se novos
dados c/egaram. "aso algum dado c/egue# a funo uip8conn esta%elecer6 a cone0o entre os dois
pontos. Se ocorrer algum pro%lema na cone0o# o uip8a*ort reali,a o processo de a%ortar a cone0o.
Para se processar um dado de entrada# a funo uip8input 3 c/amada $uando a camada de
enlace 7.=< rece%er novos dados da rede. Os pacotes devem ser mantidos no uip8*uf e o taman/o do
pacote deve ser mantido na vari6vel uip8len. Juando a funo retorna# pode /aver um pacote de sa-da
novo colocado no *uffer uip8*uf. Se assim for# a vari6vel uip8len 3 definida como o comprimento do
pacote. Se nen/um pacote deve ser enviado# a vari6vel uip8len 3 definida como ,ero.

Tra$#mi!i$do Dado#
Juando os dados so transmitidos# o u'P a)usta o taman/o dos dados a serem transmitidos pela
aplicao de acordo com o espao no *uffer dispon-vel e a )anela T"P atual anunciada pelo receptor. (
$uantidade de espao no *uffer 3 derminada pela configurao da memria. (ssim# 3 poss-vel $ue
todos os dados enviados a partir do pedido no c/eguem ao receptor. Para evitar perdas o aplicativo
pode usar a funo uip8mss para verificar a $uantidade de dados $ue realmente deve ser enviado pela
pil/a# sem $ue /a)a esse tipo de perda.
Fiura ((. Diagrama de %locos dos processos de envio de um novo pacote.
( aplicao transmite dados usando a funo do u'P uip8send. !ssa funo usa dois
argumentos: um ponteiro para o dado a ser enviado e o taman/o do dado. Se o aplicativo precisa de
espao na memria para a manipulao do dado atual a ser enviado# o uip8*uf pode ser usado para este
propsito. Para isso# 3 utili,ado o ponteiro uip8sappdata, $ue ir6 apontar a posio de memria no
uip8*uf! O aplicativo pode enviar apenas uma parte dos dados por ve, em uma cone0o# e no 3
poss-vel c/amar o uip8send mais de uma ve, por aplicativo. Portanto# somente os dados da Kltima
c/amada sero enviados.
Re!ra$#mi##o
(s retransmiss+es so reali,adas pelo timer peridico. Todas as ve,es $ue o timer peridico 3
e0ecutado# o tempo da retransmisso para cada cone0o 3 decrementado. Se o tempo c/egar a ,ero# a
retransmisso ser6 feita. "omo o u'P no mant3m o conteKdo do pacote depois destes terem sido
enviados pelo driver# o u'P re$uer $ue a aplicao faa um papel ativo na reali,ao da retransmisso#
=N
Close
Estado de
Transfer8ncia
Esta/elece
cone'$o
Close
9etransmiss$o
Close
uip7close
uip7close
uip7close
uip7conn
Error/
a/ort
uip7a/ort
uip7send
recriando os mesmos dados $ue foram enviados anteriormente para a retransmisso.
Juando o u'P decide $ue o segmento dever6 ser retransmitido# a funo uip8re2mit 3
configurada com um fla,# indicando $ue uma retransmisso 3 necess6ria. ( aplicao verificar6 o fla,
da funo uip8re2mit $ue indica $ual pacote deve ser recriado e em seguida reprodu,ir6 o mesmo dado
$ue fora mandado anteriormente.
Fe+Ea$do a Co$e9o
( aplicao fec/a uma cone0o c/amando a funo uip8close durante uma sesso. 'sso far6
com $ue a cone0o se)a fec/ada corretamente comunicando ao host remoto. "aso ocorra um erro fatal#
a aplicao poder6 a%ortar a cone0o# e o fa, c/amando a funo uip8a*ort. Se a cone0o for encerrada
pelo host remoto# o teste de funo uip8closed 3 verdadeiro. ( aplicao pode ento encerrar a cone0o
e li%erar os recursos para novas cone0+es.
Re:or!a$do Erro#
Y6 dois erros fatais $ue podem ocorrer com uma cone0o: ou a cone0o foi a%ortada pelo host
remoto# ou os Kltimos dados da cone0o foram retransmitidos muitas ve,es e com isso foi a%ortada. O
u'P reportar6 c/amando a funo da aplicao. Dessa forma a aplicao poder6 testar $ual foi a
condio de erro utili,ando as fun+es uip8a*orted e uip8timedout para reportar o erro.
Polling
Juando a cone0o est6 ociosa# o u'P c/ama a aplicao todas as ve,es $ue o timer peridico
disparar. ( aplicao usa a funo de teste uip8poll para c/ecar se esta sendo DouvidoD pelo u'P. O
evento tem duas finalidades. ( primeira 3 para dei0ar a aplicao sa%endo periodicamente $ue uma
cone0o esta ociosa# $ue permite a aplicao fec/ar cone0+es $ue ficaram ociosas por muito tempo. O
outro propsito 3 o de dei0ar a aplicao enviar novos dados $ue forem processados. ( aplicao pode
apenas mandar dados $uando c/amado pelo u'P e# portanto# esse evento 3 o Knico procedimento de
enviar dados em uma cone0o ociosa.
CEe+aem de Por!a#
Para se detectar re$uisi+es de cone0+es em determinadas portas o u'P utili,a a funo
uip8listen! !ssa funo possui uma lista de portas referindo?se a cada aplicao podendo re)eitar uma
cone0o se a porta 3 descon/ecida. ( aplicao c/eca o campo lport da estrutura uip8conn para
desco%rir a $ual porta essa nova cone0o est6 associada. Juando um pedido de cone0o verifica uma
dessas portas# o u'P cria uma nova cone0o e c/ama sua respectiva aplicao. Dessa forma o estado do
ponteiro de teste uip8connected 3 verdadeiro pois uma nova cone0o foi criada.
E#!a5ele+e$do a Co$e9o
ma nova cone0o pode ser feita a partir da funo uip8connect. !ssa funo aloca uma nova
cone0o e define um fla, de estado# no $ual se a%rir6 uma cone0o T"P para o endereo 'P e porta
especificados# na pr0ima ve, $ue a cone0o for consultada pela u'P. ( funo uip8connect retorna um
ponteiro para a estrutura uip8conn para a nova cone0o. Se no /ouver espao livres# a funo retorna
=L
2... ( funo uip8ipaddr pode ser usada para encapsular um endereo 'P# para um vetor de dois
elementos de ;9 %its usado pela u'P# para representar os endereos 'P.
Co$!role de Flu9o
( funo uip8process 3 uma funo ro%usta# e comple0a# respons6vel pela verificao e
orientao da pil/a. 2ela se processa informa+es como: c/egada e envio de dados# comunicao com
o aplicativo# c/ecAsuns# esta%elecimento de cone0o# timer# etc. O propsito da funo no ter sido
dividida em diversas outras menores 3 $ue o taman/o do cdigo aumentaria# implicando em
so%recarregar as passagens de par*metros e o fato de $ue a otimi,ao no seria to eficiente.
( pil/a T"P5'P analisa o ca%eal/o do pacote# e c/ama a sua respectiva aplicao. !sse pacote 3
arma,enado no uip8*uf at3 $ue a aplicao o leia. "aso se)a necess6rio arma,enar esses %Btes# 3 a
aplicao $ue se enca%e desse processo# pois uma ve, lido# ser6 apagado do uip8*uf para novos dados
$ue esto c/egando ou $ue esto esperando para ser transmitidos. "aso os dados este)am fora da
se$u:ncia correta# a pil/a no encamin/ar6 os dados a aplicao.
Fiura (&. Diagrama de flu0o com as principais caracter-sticas do u'P.
Se a aplicao dese)a enviar um dado# ela deve colocar os dados dentro do uip8*uf. Para isso# o
ponteiro uip8sappdata dever6 apontar para o primeiro %Bte $ue este)a dispon-vel no *uffer para o seu
arma,enamento. ( pil/a T"P5'P calcula o seu respectivo checksun# completa os campos do header
necess6rio e finalmente envia o pacote.
>I
Camada :
uIP
%PP %PP
uip7/uff
uip7sappdata uip7appdata
uip7process23
uip7input 23 uip7send 23
08& I$!erfa+e TUN*TAP
( interface T25T(P foi criada por &a0im ErasnBansAB e &aAsim hevmenAin G>9H# com o
proposito de reali,ar uma interface de rede virtual no kernel $ue rece%e e transmite pacotes. O
T25T(P reali,a# %asicamente# as mesmas fun+es da camada ..". Podendo ser um dispositivo
simples &oint4to4&oint ou um dispositivo thernet. Do ponto de vista do kernel# a interface T25T(P
funciona %asicamente igual uma interface de rede normal# mas ao inv3s de rece%er e enviar pacotes de
um dispositivo f-sico ele se comunica com um dispositivo logico.
1edes virtuais podem ser usadas de diversas maneiras tornando?as muito fle0-veis. Feralmente#
o T25T(P 3 utili,ado em dois cen6rios. O primeiro 3 o VP2. 2esse cen6rio# o kernel envia os pacotes
para o dispositivo T2 ou T(P. !m seguida o soft@are VP2 ir6 encriptar e encamin/ar os pacotes para
o outro lado do tunelamento VP2# onde sero decriptados e entregues ao seu destino. O segundo
cen6rio 3 o caso mais tradicional# no $ual funcionam como virtuali,ador5emulador de pacotes. 2este
caso# o sistema operacional virtuali,ado se comunica com um dispositivo de rede virtual 7normalmente
um adaptador thernet virtual<. O soft@are de virtuali,ao ento cria um dispositivo T(P e os
interconecta# criando uma ponte de comunicao.
Pasicamente o T2 3 um dispositivo de rede virtual &oint4to4&oint desenvolvido para suportar
tunelamento utili,ando $uadros 'P. O T(P 3 um dispositivo de rede virtual thernet, desenvolvido para
suportar tunelamento thernet utili,ando $uadros thernet.
O T25T(P 3 composto por e0tens+es do kernel# um provendo interface T2 e a outra T(P.
!les criam um con)unto de dispositivos 5dev5tunQ e 5dev5tapQ# respectivamente# onde o Q 3 o
identificador da interfaces virtuais. Juando a primeira interface 3 criada# ela 3 denominada de 5dev5tapI
ou 5dev5tunI dependendo do dispositivo e# pode?se atri%uir um endereo a ela da mesma forma $ue 3
feito em um interface de rede normal. (ps a configurao da interface# os pacotes $ue o kernel enviou
atrav3s da interface 7determinados pela ta%ela de roteamento< podem ser verificados por sua ve, no
dispositivo de rede 7utili,ando um tcpdump por e0emplo<.
!ssa forma de interface virtual vem se populari,ando cada ve, mais. Diversas plataformas#
como FreePSD# .inu0# &a0 OS Q# Solaris# Cindo@s a adaptaram. ! diversos redes privadas virtuais o
utili,am# como OpenVP2# OpenSSY# Yamac/i e 2eo1outer.
( pil/a T"P5'P u'P no possui um driver $ue se comunica com a camada f-sica# pois a ideia do
desenvolvedor# (dam DunAels G==H# foi a de desenvolver uma pil/a T"P5'P $ue poderia ser usada em
diversos tipos de microcontroladores por e0igir pouco recurso de processamento e memria para seu
funcionamento. .ogo# o T25T(P foi usado para esse proposito# afim de su%stituir virtualmente o
driver.
Para a utili,ao da interface T25T(P do ni0 primeiramente 3 preciso configura?lo para $ue
possa identificar o u'P e criar o tunelamento entre o T25T(P e o prprio u'P. ma das configura+es
$ue so feitas no u'P 3 o endereo 'P do destino $ue ir6 esta%elecer comunicao. 2essa funo de
configurao# 3 preciso identificar o endereo 'P da interface T25T(P# para $ue o u'P possa
esta%elecer uma cone0o com o dispositivo virtual. 'sso 3 feito configurando o respectivo endereo da
interface T25T(P na funo uip8ipaddr do u'P.
(s pr0imas etapas de configurao das interfaces so reali,adas no prprio shell do ni0. (
criao da interface T25T(P e a configurao do seu identificador e do endereo 'P. O endereo
como )6 citamos deve ser o mesmo do u'P.
Para $ue o tr6fego da interface T25T(P possa c/egar a interface de rede et/I# o ni0 e0ige
$ue uma terceira interface de controle se)a criada para reali,ar o papel de uma ponte entre o T25T(P
e a interface de rede et/I.
>;
Fiura (/. Tr6fego entre as interfaces. T25T(P e et/I atrav3s da ponte %rI.
"onse$uentemente a interface %rI tam%3m ter6 um identificador e um endereo 'P# para $ue a
interface T25T(P e et/I possam transmitir os pacotes de dados. ( interface et/I est6 vinculado com
o adaptador de rede do computador# com isso# se incum%ir6 de transmitir os dados para o meio f-sico.
Muda$a# fei!a# $o +,dio
Foram feitas mudanas no cdigo com o intuito de identificao dos servios multim-dia
utili,ando campos do header 'Pv8 e 'Pv9. O protocolo 'Pv8 e 'Pv9 possuem por padro campos de
identificao. !sses campos identificam $ual o tipo de segmento $ue esta dentro do pacote 'P.
Dispositivos intermedi6rios e hosts podem verificar esses campos para fa,erem uma rotina de
prioridade de n-vel mais %ai0o# na camada de rede# aumentando o desempen/o entregando o pacote
com uma menor lat:ncia.
Para a identificao dos servios utili,amos os campos Type of Service do 'Pv8 e Traffic Class e
Tcflo. do 'Pv9. 'nicialmente esses campos )6 e0istiam no u'P# mas eram preenc/idos com ,ero. Pits de
redund*ncia eram inseridos para completar o taman/o total do header a ser transmitido. !nto
retiramos os %its de redund*ncia e inserimos identificadores para servios de vo,# v-deo# 6udio e dados.
(l3m da identificao implementamos uma funo para gerar a estat-stica dos servios. (ssim
conseguimos sa%er a $uantidade $ue foi gerada de cada servios e $uantos pacotes associados a cada
servio foram transmitidos. ! atrav3s da comparao com a estat-stica registrada no receptor
conseguirmos calcular a $uantidade de servios perdidos# servios completados# e retransmiss+es de
cada servio.
Pro5lema# e$+o$!rado#
(ps a configurao dos endereos 'P das interfaces 7T25T(P# %rI# et/I<# portas# e a criao
da ponte# foi poss-vel reali,ar testes para verificar sua confia%ilidade. O teste mais comum para este
tipo de situao 3 Zpingar[ as interfaces. O pin, %asicamente 3 uma mensagem enviada de um host para
outro host# afim de identificar se ele rece%e e se transmite de volta um recon/ecimento 7ack).
Para a reali,ao deste teste utili,amos uma ferramenta 7tcpdump< $ue possi%ilitou c/ecarmos
todos os %its $ue c/egam e saem das interfaces. Dessa forma conseguimos identificar com preciso se o
$uadro $ue saiu de uma das interfaces 3 o mesmo $ue c/egou na outra.
O resultado do teste constatou $ue a ponte estava se comunicando corretamente. Todas as
interfaces se comunicaram sem perda de pacotes. ! todo o tr6fego $ue c/egava em uma delas# por
e0emplo na et/I# era automaticamente transmitido para a ponte# $ue por sua ve, a enviava para o
T25T(P.
>=
TU#/T%P eth0
/r0
O pr0imo passo seria enviarmos com sucesso algum $uadro da pil/a u'P para o T25T(P. O
u'P# )untamente com a pil/a T"P5'P# possui e0emplos de aplicao para $ue possamos testar a pil/a e#
tam%3m# para podermos aprender o seu funcionamento. !ssas aplica+es de e0emplo vo de um
simples Yello?Corld a um Ce%"lient. Por fim# tentamos enviar para a interface um $uadro com todas
as aplica+es e nen/uma delas teve sucesso. !m principio# nen/uma delas compilavam# em diversos
caso /aviam lin/as de cdigo pela metade# ou fun+es faltando par*metros. !m cada aplicao testada
foi preciso desenvolver novamente a aplicao para consertar os erros $ue /aviam nos e0emplos.
2o total foram $uatro aplica+es testadas# Yello?Corld# S&TP# Ce%"lient# e Ce%Server. !m
todas elas somente aps muita correo e implementao a pil/a compilou. &as ao e0ecuta?las nen/um
%it c/egava ao T25T(P. &ais uma ve, aps varias verifica+es constatamos pro%lemas na funo $ue
transmite os dados# a funo uip8send9).
( depurao mostrou $ue o u'P possui a opo de transmitir os $uadros para a interface
T25T(P# mas ela no foi desenvolvida. Dessa forma# a pil/a e0ige o desenvolvimento de um driver
para o seu funcionamento. m driver $ue utili,e a interface T25T(P ou $ue se comuni$ue
diretamente com o meio f-sico. Para am%os os casos# o mais seguro 3 desenvolver um driver $ue se
comuni$ue diretamente com o meio f-sico para evitar futuros pro%lemas com a interface T25T(P.
Outro ponto 3 o fato do u'P ter sido desenvolvido para ser implementado em
microcontroladores de %ai0a capacidade# onde sua ar$uitetura foi pro)etada para atender a um flu0o de
dados mais restrito# tendo em vista a utili,ao de apenas um *uffer glo%al de arma,enamento de
pacotes para todas as fun+es $ue a camada de rede deve suportar. 'sso pode aca%ar tornando?se# para a
nossa a%ordagem# um pro%lema de velocidade de processamento no envio e recepo dos pacotes# )6
$ue o volume de tr6fego $ue utili,amos 3 elevado.
"om o surgimento dessas inconveni:ncias /ouve um aumento na $uantidade de atividades a
serem feitas. (ssim um estudo mais amplo com as simula+es do (1!2( foi proposto.
>>
18 Modelo# de Simulao
Simula+es# como a maioria dos m3todos de an6lise# envolvem sistemas e modelos $ue os
representam G;LH. 2este cap-tulo daremos alguns e0emplos dos tipos de modelos de simulao e sua
descrio# para $ue# em seguida# analisemos os modelos $ue propomos.
( funo de um modelo 3 descrever o funcionamento da realidade atrav3s de um pe$ueno
nKmero de vari6veis $ue permita a sua representao. !0istem diferentes tipos de modelos de
simulao. Os modelos comumente utili,ados so os modelos f-sicos# lgicos ou matem6ticos. ( seguir
veremos alguns e0emplos G>NH:
Modelo F"#i+o: 2este tipo de modelo 3 criada uma maior afinidade com a realidade# visto $ue a
simulao 3 e0perimentada como real. "omo por e0emplo# simula+es de salas de controle com
o proposito de treinar tra%al/adores em situa+es de plane)amento5acidente nuclear. Simulao
de v]o real# para treinar pilotos em casos de panes# como $ueda de energia# pro%lemas com o
trem de pouso# e etc.
Modelo L,i+o: &odelos lgicos so apro0ima+es e suposi+es# tanto estrutural $uando
$uantitativo# em como o sistema tra%al/a ou como deve tra%al/ar. O modelo lgico 3
normalmente representado em um programa de computador# podendo ser utili,ado para
diversos fins# como estudar o comportamento de um determinado cen6rio.
Modelo Ma!em!i+o: So utili,ados para estudar situa+es e0tremas# dificilmente o%servadas
na realidade.
ma segunda forma de classificao de mdulos 3 a relao entre os elementos envolvidos#
podendo ser classificada das seguintes formas:
E#!!i+o# ou Di$Fmi+o#: denominam?se como modelos est6ticos os $ue visam representar o
estado de um sistema em um instante ou $ue em suas formula+es no se leva em conta a
vari6vel tempo# en$uanto os modelos din*micos so formulados para representarem as
altera+es de estado do sistema ao longo da contagem do tempo de simulao.
De!ermi$"#!i+o ou E#!o+#!i+o: so modelos determin-sticos os $ue em suas formula+es no
fa,em uso de vari6veis aleatrias# en$uanto os estoc6sticos podem empregar uma ou mais
vari6veis aleatrias.
Di#+re!o# ou Co$!"$uo#: so modelos discretos a$ueles em $ue o avano da contagem de
tempo na simulao se d6 na forma de incrementos cu)os valores podem ser definidos em
funo da ocorr:ncia dos eventos ou pela determinao de um valor fi0o# nesses casos s sendo
poss-vel determinar os valores das varia+es de estado do sistema nos instantes de atuali,ao
da contagem de tempog en$uanto para os modelos cont-nuos o avano da contagem de tempo na
simulao d6?se de forma cont-nua# o $ue possi%ilita determinar os valores das vari6veis de
estado a $ual$uer instante.
Propomos tr:s diferentes modelos de simulao para am%ientes multim-dia# onde servios
stream e el6stico so re$uisitados ao mesmo tempo pelos usu6rios. 2o modelo ; foram reali,ados
simula+es propondo um estudo de demanda de re$uisi+es dos usu6rios# onde tr:s cen6rios foram
estudados. O primeiro 3 $uando ocorre um aumento repentino de usu6rios# com isso diminuindo o
intervalo de re$uisi+es dos servios. O segundo cen6rio# $uando a durao dos servios aumenta#
ocorrendo %lo$ueios de novos servios por falta de recursos# por e0emplo# troncos em um central
>8
telef]nica. ! o terceiro cen6rio 3 com relao ao "ontrole de (dmisso de "/amada 7"("< do sistema.
!sses tipos de situa+es so amplamente estudadas em casos de mudanas do comportamento de
tarifao das empresas de telefonias mvel e fi0a# onde a co%rana no 3 mais feita por minutos
utili,ados# mas sim por c/amadas feitas# aumentando significativamente a durao das c/amadas. !sse
tipo de estudo 3 crucial por parte das empresas para no acarretar em uma %ai0a Jualidade de Servio e
%lo$ueios de c/amadas elevados infringindo as regras da (2(T!..
O modelo = e > so am%ientes VP2# onde 3 estudado o Sojourn# tempo $ue o pacote leva para
c/egar ao host de destino# de um servio el6stico. Veremos cada um com mais detal/es neste capitulo.
( principal diferena entre os dois modelos 3 $ue o modelo = no apresenta a implementao de
atri%utos como jitter e lat:ncia# en$uanto $ue o modelo > os possui.
Para reali,ar as simula+es foi utili,ado a verso de Zestudante[ do simulador (1!2( ;=.I. (
principal diferena entre da verso de Zestudante[ e a completa 3 $ue ela possui um limite de entidades
simult*neas. Por causa disso algumas simula+es $ue gostar-amos de ter e0ecutado no foi poss-vel#
por$ue ultrapassavam as ;OI entidades $ue a verso de Zestudante[ permite. Para as simula+es foi
utili,ado o /ard@are:
2ote%ooA (cer (spire OO>IF
(&D Turion Q= ltra 98 %its# =.=F/,
&emria 1am de = F%
Cindo@s M
O tempo de simulao varia de ; /ora a ;I /oras para cada simulao# dependendo dos
par*metros utili,ados. 2o total foram e0ecutados ;LI simula+es para os tr:s modelos propostos.
!m cada modelo utili,amos diferentes valores de replica+es. Juanto maior o nKmero de
replica+es mais preciso o resultados so. Por outro lado o seu aumento resulta em tempos maiores
para o termino da simulao# invia%ili,ando simular um nKmero grande de diferentes cen6rios e
par*metros. !m cada modelo utili,amos valores diferentes de replica+es. Seus valores so citados na
descrio de cada modelo.
O campo .arm4up define o tempo necess6rio para alcanar condi+es de estado estacion6rio.
2os modelos de simulao ;# = e > utili,amos valores igual a ;III segundos.
18( Modelo de Simulao (
O primeiro modelo de simulao 3 o estudo de um am%iente stream# onde temos tr:s servios :
Videoconfer:ncia# V-deo?"lip# e V-deo $n (emand. "ada servio possui padr+es diferentes de
comportamento# como durao do servio# intervalo entre as re$uisi+es dos servios# "("# e fun+es
de distri%ui+es. "omo )6 discutido anteriormente# com esse estudo analisaremos a $uantidade de
servios completados# re)eitados e a $uantidade total gerada dependendo da demanda atri%u-da ao
sistema. \ importante citarmos a import*ncia de um estudo de JoS para $ue /a)a uma margem de
toler*ncia caso ocorra um pico acima do normal e tam%3m para $ue no ocorra nen/um erro ao se
pro)etar uma rede. Para isso# utili,aremos tr:s cen6rios diferentes. 2a refer:ncia G>MH encontram?se as
simula+es $ue veremos neste modelo. !les so:
"en6rio (: Variao do intervalo de re$uisio dos servios.
"en6rio P: Variao da durao dos servios.
"en6rio ": Variao do controle de admisso de c/amadas.
>O
O modelo utili,ado para os tr:s cen6rios foi o mesmo# e ser6 detal/ado a seguir.
Fiura (0. Workspace do (1!2(. &odelo de simulao ;.
18(8( O modelo
O modelo possui tr:s %locos Arrive# $ue so os respons6veis pela gerao dos servios#
Videoconfer:ncia# V-deo?Clip# e V-deo $n (emand! "ada %loco possui valores $ue representam seus
servios e fun+es de distri%uio. Para cada servio e0istem duas sa-das# uma para os servios
re)eitados e outra para os completados. .evando a um total de seis sa-das.
(ps a gerao do servios# o %loco Choose verificar6 $ual servio $ue foi gerado e
encamin/ar6 ao respectivo %loco Assi,n do servio. O %loco Assi,n ir6 ento incrementar a vari6vel
T*uffVideoConf por e0emplo# indicando $ue um servio de Videoconfer:ncia est6 sendo solicitado e
ocupar6 mais um espao no sistema. !m seguida um outro %loco Choose# verifica as vari6veis
T*uffVideoConf e a )im8VideoConf# a vari6vel )im8VideoConf 3 a respons6vel pelo "ontrole de
(dmisso de "/amada 7"("< do servio em particular. "aso o valor do T*uffVideoConf se)a maior $ue
o aceit6vel pelo "("# o servio ser6 %lo$ueado e encamin/ado para o Assi,n respons6vel pela sa-da
dos servios re)eitados# e o respectivo contador ser6 incrementado. Por outro lado# caso se)a aceito# o
%loco Assi,n ir6 decrementar uma parte do tempo total da durao do servio# durao $ue foi
determinado pela funo de distri%uio do %loco Arrive $ue criou o servio. (ps decrementar a
durao do servio# c/egamos no %loco &rocess# $ue 3 o respons6vel pelo processamento. 2ele teremos
>9
influ:ncias do codec do servio# capacidade de processamento# e regras de filas. Todo esse processo
simular6 a lat:ncia do servidor ou host. Por final# um Kltimo %loco Choose, analisa o tempo de durao
restante para completar o servio. "aso a durao no ten/a terminado 3 feito um loop*ack repassando
todos os processos novamente at3 $ue a durao do servio ten/a aca%ado# indicando o encerramento
do servio.
(s vari6veis glo%ais so inseridas no %loco Varia*les! So vari6veis de controle# como o "("
de cada servio# e o taman/o do canal! &ais detal/es so%re os %locos se encontram no ap:ndice (.
18(8& Co$fiura;e# da# #imula;e#
Para a reali,ao das simula+es foi utili,ado diferentes fun+es de distri%ui+es. Para o servio
videoconfer:ncia utili,amos a distri%uio e0ponencial para gerar a durao do servio e o intervalo
entre re$uisi+es dos servios. 2o v-deo clip e v-deo on demand foram utili,ados a distri%uio normal
no intervalo entre re$uisi+es do servios# e e0ponencial para a durao do servio. O canal foi
configurado a >N8 A%ps# e utili,amos replica+es igual a ; e O. 2a Ta%. 9 esto os par*metros iniciais de
cada servio.
Videoconfer:ncia: Foi utili,ado a funo de distri%uio e0ponencial no intervalo entre
re$uisi+es do servio e durao do servio.
V-deo $n (emand: Foi utili,ado funo de distri%uio e0ponencial no intervalo entre
re$uisi+es do servio. ! funo de distri%uio normal na durao do servio.
V-deo Clip: Foi utili,ado funo de distri%uio e0ponencial no intervalo entre re$uisi+es do
servio. ! funo de distri%uio normal na durao do servio.

Par*metros V-deo clip V-deo on4demand Videoconfer:ncia
Durao do $uadro ou tempo entre
pacotes 7ms<
=I =I =I
Taman/o m60imo do pacote7%Btes< L= L= L=
Ta0a Codec 7A%ps< >= >= >=
Taman/o do pacote 7%Btes< NI NI NI
Durao m3dia do servio 7segundos< >II M=II LII
Desvio padro 7segundos< ;NI LII j
'ntervalo m3dio de c/egada dos servios LII ;88II >9II
&60imo de servios simult*neos 8 = =
Ta5ela 2. Valor dos par*metros iniciais utili,ados para a simulao.
2o asterisco# o servio de videoconfer:ncia esta seguindo um distri%uio e0ponencial# dessa
forma no possui um desvio padro.
O (1!2( no possui um campo especifico para inserir o codec do servio# logo temos $ue
atri%uir para cada servio o taman/o do $uadro. O taman/o do $uadro 3 utili,ado $uando o servio 3
processado no %loco process# para $ue possa calcular o tempo $ue o servio deve permanecer no %loco
at3 $ue todo o tempo respectivo ao codec ten/a se esgotado# significando $ue a ta0a do codec foi
satisfeita. ( seguir veremos o calculo para os tr:s servios simulados. "omo os tr:s servios utili,am a
>M
mesma ta0a de codec o calculo ser6 o mesmo:

Ta2a doCodec (
*it
s
)(ura:;o do'uadro(s)=Slice(*it ).
7;9<
Para um codec de >= A%ps temos:

>=k*ps ->=III
*it
s
(=I;I
>
s)=98I*its .
7;M<
2o %loco process temos:

Tamanho do'uadro
Ta2a docanal
=
5it
5it / s
=se,undos.
7;N<
Para simularmos o estudo proposto foi reali,ado a variao de um par*metro por ve,# com o
o%)etivo de causar um colapso no sistema. Dessa forma conseguimos traar gr6ficos com a $uantidade
de servios completados e re)eitados em funo do intervalo entre re$uisi+es# durao e "(" dos
servios. ! atrav3s dele# notar os pontos $ue o <oS dei0a de ser satisfatrio# onde o nKmero de usu6rio
esta muito acima do $ue o sistema suporta# no conseguindo reservar recurso para a demanda.
Os par*metros da Ta%. 9 servem como uma referencia para a simulao. (o se encerrar o estudo
de um cen6rio# voltamos com os valores contidos na Ta%. 9 para comearmos o estudo de um outro
cen6rio.
18(8/ Re#ul!ado#
Ce$rio A
2o cen6rio ( reali,amos simula+es variando o intervalo de re$uisio de c/egada dos servios.
"omo temos tr:s servios# foram simulados tr:s casos. Juando ocorre a variao do intervalo de
c/egada do servio de videoconfer:ncia# $uando ocorre do v-deo clip e $uando ocorre do v-deo on
demand. Os casos foram simulados focando um servio por ve,# para $ue possamos ver o
comportamento de cada servio separado. !0istem inKmeros casos e cen6rios poss-veis a serem
simulados# mas como a nossa ideia no 3 focarmos em apenas um modelo de simulao# tivemos $ue
fa,er uma seleo dos $ue mais agregam informa+es.
>N
Fiura (1. Juantidade de videoconfer:ncias em funo do intervalo m3dio entre re$uisi+es. ( lin/a
preta representa o nKmero total de videoconfer:ncias# a a,ul as conclu-das# e a vermel/a as perdas. (
durao m3dia da videoconfer:ncia foi fi0ada em LII segundos e "(" igual a =.
"omo podemos ver o comportamento das lin/as preta e vermel/a da Fig. ;O esto seguindo
uma distri%uio e0ponencial como esperado. 2os intervalos de re$uisi+es mais fre$uentes o sistema
no consegue garantir recursos para todos os usu6rios. 'sso se deve ao "(" e a durao m3dia do
servio. "omo a durao foi configurada em LII segundos e o sistema suporta apenas = c/amadas
simult*neas ocorre uma %lo$ueio de c/amas de at3 NM#Od para o pior caso# 9I segundos. (penas a
partir de =8II segundos os %lo$ueios ficam aceit6veis# com menos de =d de %lo$ueio# $ue 3 um valor
padro aceit6vel.
>L
;0 <:0 <=0 :>0 ?00 ;00 <:00 :>00 ?000 ?;00 ;000 <:000 ?0000
0
:00
>00
;00
=00
<000
<:00
<>00
<;00
<=00
Total
Conclu)das
Perdas
Intervalo @Adio entre 9equisi"Bes 2segundos3
u
a
n
t
i
d
a
d
e

d
e

(
)
d
e
o
c
o
n
f
e
r
8
n
c
i
a
Fiura (2. Juantidade de v-deos on demand em funo do intervalo m3dio entre re$uisi+es. ( lin/a
preta representa o nKmero total de v-deos on demand# a a,ul as conclu-das# e a vermel/a as perdas. (
durao m3dia do v-deo on demand foi fi0ada em M=II segundos com desvio padro de LII segundos#
utili,ando funo de distri%uio normal e "(" igual a =.
2o caso do v-deo on demand o nKmero de servios completados foram m-nimos# devido a
durao elevada do servio# c/egando a um %lo$ueio de LN#>d para 9I segundos. O desta$ue na Fig.
;9# mostra os intervalos entre re$uisi+es de servio $ue comeam a ser aceit6veis. 2a Fig. ;M
podermos analisar?lo mel/or# ampliando a regio.
Foram feitas simula+es com valores maiores do $ue >9II segundos para podermos c/egar ao
valor em $ue a ta0a de %lo$ueio se)a inferior a ;d. Podemos notar $ue mesmo aumentando o intervalo
entre re$uisi+es do servio pode ocorrer casos em $ue o %lo$ueio aumente comparado com um
intervalo menor# como 3 o caso do ;NIII segundos. 'sso ocorre por$ue um novo servio foi gerado e o
sistema )6 contem = servios em e0ecuo# devido a dura+es elevadas $ue um servio de v-deo on
demand pode durar.
8I
;0 <:0 <=0 :>0 ?00 ;00 C00 <=00 :D00 ?;00 D:00 <0=00 <>>00
0
:00
>00
;00
=00
<000
<:00
<>00
<;00
<=00
Total
Completado
Perdido
u
a
n
t
i
d
a
d
e

d
e

(
)
d
e
o

6
n

D
e
m
a
n
d
Fiura (3. Trec/o destacado na Fig. ;9. "omportamento do v-deo on demand entre o intervalo >9II a
=;9II segundos.
Fiura (). Juantidade de v-deo clips em funo do intervalo m3dio entre re$uisi+es. ( coluna preta
representa o nKmero total de v-deo clips# a a,ul as conclu-das# e a vermel/a as perdas. ( durao
m3dia do v-deo clips foi fi0ada em >II segundos e desvio padro de ;NI segundos# utili,ando a
distri%uio normal e "(" igual a 8.
8;
<0 ?0 ;0 <:0 <=0 :>0 ?00 ;00 C00
0
:000
>000
;000
=000
<0000
<:000
Total
Completado
Perdido
u
a
n
t
i
d
a
d
e

(
)
d
e
o

C
l
i
p
?;00 <0=00 <:;00 <>>00 <=000 :<;00
0
:
>
;
=
<0
<:
<>
<;
<=
Total
Completado
Perdido
Intervalo entre 9equisi"Bes 2segundos3
u
a
n
t
i
d
a
d
e

(
)
d
e
o

6
n

D
e
m
a
n
d
Por possuir um "(" maior $ue dos demais servios# e uma durao de servio pe$uena# o
v-deo clips foi o Knico servio $ue conseguiu c/egar a padro aceit6veis de %lo$ueio. Sendo $uase
todos os intervalos entre re$uisi+es de servio sem %lo$ueios. (penas /ouve %lo$ueio em intervalos
muito %ai0os# como ;I segundos e >I segundos. ( ta0a de servios completados foi de LL#9d para ;I
segundos# e LL#L;d para >I segundos.
Ce$rio -
2o cen6rio P reali,amos simula+es variando a durao dos servios. Temos tr:s casos# cada
um referente a um servio.
Fiura (4. Juantidade de videoconfer:ncias em funo da durao m3dia da videoconfer:ncia. ( lin/a
preta representa o nKmero total de videoconfer:ncias# a a,ul as conclu-das# e vermel/a as perdas. O
intervalo m3dio entre re$uisi+es da videoconfer:ncia foi fi0ado em >9II segundos e "(" igual a =.
(s dura+es menores $ue >9II segundos no esto presentes na Fig. ;L por$ue ocorreu uma
repetio dos resultados entre 9I a >9II segundos# total de ;M servios# ;M completados e I perdido.
'sso se deve principalmente por$ue o intervalo entre re$uisi+es dos servios 3 de >9II segundos.
.ogo# a durao dos servios so pe$uenas demais para o intervalo dos servios# dei0ando o sistema
ocioso para novas re$uisi+es de servio.
2a Fig. =I# podemos notar $ue para a durao de M=II segundos o nKmero total de servios no
3 igual a soma dos servios completados e perdidos. Fre$uentemente isso ocorre devido ao tempo total
da simulao $ue se encerra antes $ue o tempo do servio ten/a sido completado. Podemos considerar
poe e0emplo esse caso como um servio corrompido# onde um link se rompe durante uma transfer:ncia
ou o host 3 desligado.
8=
?;00 ;000 <:000 ?0000 ?;000 >:000 >=000 E>000 ;0000
0
:
>
;
=
<0
<:
<>
<;
<=
Total
Conclu)das
Perdas
Dura"$o @Adia da (ideoconfer8ncia 2segundos3
u
a
n
t
i
d
a
d
e

d
e

(
)
d
e
o
c
o
n
f
e
r
8
n
c
i
a
Fiura &'. Juantidade de v-deos on demand em funo da durao m3dia do v-deo on demand. ( lin/a
preta representa o nKmero total de v-deos on demand# a a,ul as conclu-das# e a vermel/a as perdas. O
intervalo entre re$uisi+es do servio foi fi0ado em ;88II segundos e "(" igual a =.
Fiura &(. Juantidade de v-deo clips em funo da durao m3dia do v-deo clips. ( lin/a preta
representa o nKmero total de v-deo clips# a a,ul as conclu-das# e a vermel/a as perdas. O intervalo entre
re$uisi+es do servio foi fi0ado em LII segundos# e "(" igual a 8.
8>
?00 <=00 D:00 <0=00 <>>00 ?0000 D0000
0
:0
>0
;0
=0
<00
<:0
Total
Conclu)das
Perdas
Dura"$o @Adia do ()deo Clip 2segundos3
u
a
n
t
i
d
a
d
e

d
e

(
)
d
e
o

C
l
i
p
>=00 D:00 <>>00 ?0000 D0000 <00000
0
<
:
?
>
E
;
D
=
C
Total
Conclu)das
Perdas
Dura"$o @Adia do ()deo 6n Demand 2segundos3
u
a
n
t
i
d
a
d
e

d
e

(
)
d
e
o

6
n

D
e
m
a
n
d
Ce$rio C
2o cen6rio " foi reali,ado simula+es variando o controle de admisso de c/amadas. !sse
cen6rio reflete uma ao dos administradores da rede# com o intuito de mel/orar a estrutura f-sica da
rede para $ue possa suportar a nova demanda de recursos dos usu6rios. "omo a instalao de um
nKmero maior de troncos em um central de comutao.
(trav3s das simula+es deste cen6rio podemos analisar a $uantidade de "(" necess6rio para
suportar os servios de forma $ue no /a)a um nKmero de perdas elevado.
Fiura &&. Juantidade de videoconfer:ncias em funo ao nKmero m60imo de videoconfer:ncia
simult*neos. ( lin/a preta representa o nKmero total de videoconfer:ncia# a a,ul as conclu-das# e a
vermel/a as perdas. ( durao m3dia e intervalo entre re$uisi+es dos servios so >IIII e >9II
segundos respectivamente. m valor e0agerado de durao de servio foi utili,ado para podermos
visuali,ar o efeito das mudanas no nKmero m60imo de servios simult*neos.
&antendo a m3dia do intervalo entre re$uisi+es e durao dos servios fi0os# podemos variar o
nKmero m60imo de servios simult*neos. Podemos ver a supresso dos servios re)eitados e o
resta%elecimento dos servios conclu-dos resta%elecida conforme aumentamos o nKmero m60imo de
servios simult*neos.
O intervalo m3dio entre re$uisi+es de servios da Fig. => 3 o do%ro da durao do servio#
resultando em ;IId de servios conclu-dos $uando temos dois ou mais servios simult*neos. Devemos
lem%rar $ue uma rede est6 sempre em constante crescimento# sendo positivo considerar margens de
seguranas para $ue picos ou um aumento repentino na demanda no comprometa a rede.
88
< : ? > E ; D
0
:
>
;
=
<0
<:
<>
<;
<=
Total
Conclu)das
Perdas
#Fmero @'imo de (ideoconfer8ncia !imultGneos
u
a
n
t
i
d
a
d
e

d
e

(
i
d
e
o
c
o
n
f
e
r
8
n
c
i
a
2o caso do servio de v-deo clips# mostrado na Fig. =8 segue as mesmas fun+es de distri%uio
da Fig. =># sua diferena so os valores do intervalo m3dio entre re$uisi+es e durao do servio.
2este caso# podemos notar $ue a rede se encontra ociosa em intervalos longos# por$ue em nen/um
momento 3 gerado dois servios de v-deo clip ao mesmo tempo.
Fiura &/. Juantidade de v-deos on demand em funo ao nKmero m60imo de v-deo on demand
simult*neos. ( lin/a preta representa o nKmero total de v-deos on demand# a a,ul as conclu-das# e a
vermel/a as perdas. ( durao m3dia e intervalo entre re$uisi+es dos servios so M=II e ;88II
segundos respectivamente.
Fiura &0. Juantidade de v-deo clips em funo do nKmero m60imo de v-deo clips simult*neos. (
lin/a preta representa o nKmero total de v-deo clips# a a,ul as conclu-das# e a vermel/a as perdas. (
durao m3dia e intervalo entre re$uisi+es dos servios so >II e LII segundos respectivamente.
8O
< : ? >
0
<
:
?
>
E
;
D
=
C
Total
Conclu)das
Perdas
#Fmero @'imo de ()deo 6n Demand !imultGneos
u
a
n
t
i
d
a
d
e

d
e

(
)
d
e
o

6
n

D
e
m
a
n
d
< : ? >
0
:0
>0
;0
=0
<00
<:0
Total
Conclu)das
Perdas
#Fmero @'imo de ()deo Clip !imultGneos
u
a
n
t
i
d
a
d
e

d
e

(
i
d
e
o

C
l
i
p
18& Modelo de Simulao &
O modelo sup+e o dimensionamento de uma rede com 9 tipos diferentes de servios# sendo O do
tipo stream e apenas um do tipo el6stico 7c/amado de Dados<# como segue a ta%ela a seguir.
Servio 'ntervalo entre
1e$uisi+es
Durao 7s< Tr6fego 7!rl<
Videoconfer:ncia ; c/amada5/ LII I.=O
V-deo $n (emand I.=O c/amada5/ M=II I.OI
Dados ; ar$uivo5>IIs 7j< >O
V-deo Clips 8 c/amadas5/ >II I.>>
Vo'P 7P(PQ< ;II c/amadas5/ ;NI O
"*mera 'P ; $uadro5s ; ;
Ta5ela 3. Par*metros de intervalo# durao e tr6fego dos servios.
2o asterisco# o servio de Dados so gerados com uma m3dia de taman/o igual a N8 A%Btes#
pr0imo ao de G=9H# onde a transmisso depende da velocidade da rede. ! tam%3m# a m3dia do taman/o
do servio gerado pelo servio de Dados 3 determinado dividindo N8III0N por 98 A%it5s
correspondente granularidade m-nima do canal de vo, sem compresso# resultando em ;I.Os. 2ote
$ue I.I>O !rl a 7;5>II<.7N8III.N598III<. "ada servio individual Vo'P 3 um P(PQ $ue corresponde a
O !rl.
(ssumindo $ue os servios gerados pelo Vo'P e videoconfer:ncia possuem caracter-sticas
semel/antes ao servio de vo, por comutao de circuitos# podemos a)ustar a durao desses servios
pela distri%uio de pro%a%ilidade e0ponencial G=MH. ( partir de pressupostos semel/antes# ns
adotamos $ue o intervalo entre as re$uisi+es dos servios seguem a distri%uio e0ponencial.
Os servios v-deo on demand e v-deo clip tam%3m seguem a distri%uio e0ponencial para os
intervalos entre re$uisi+es. !ntretanto# a distri%uio de durao do servio tem caracter-sticas
Faussinas. 2o caso do v-deo on demand# a m3dia de durao 3 de M=II segundos com um desvio
padro de LII segundos. ! no caso v-deo clips a media de durao 3 de >II segundos com um desvio
padro de ;II segundos. O modelo assume $ue o servio "*mera 'P re$uer uma %anda de >= A%it5s
7codec &P!F?8<# para transmitir um $uadro por segundo em uma Knica direo.
O sistema ser6 simulado com dois tipos de cen6rios: sem prioridade e com prioridade. 2o caso
sem prioridade todos os servios tero a mesma prioridade. Para o caso com prioridade todos os
servios stream tero alta prioridade# e o servio el6stico 7Dados< ter6 %ai0a prioridade. Dessa forma#
en$uanto os servios stream so designados para ter um %lo$ueio m60imo de =d# o de Dados# com
%ai0a prioridade# no poder6 ter delays maiores $ue ;O segundos na entrega de um ar$uivo de ;II
A%Btes 7e$uivalentemente a N8 ABtes em ;=.9 segundos<.
18&80 De!alEame$!o do Modelo
O modelo simulado pode ser visto como uma estaco de tra%al/o ou um servidor $ue prove
servios a usu6rios ou entidades. 2o caso do tr6fego stream# o conceito de durao do servio 3
acompan/ado pelo conceito de largura de %anda efetiva# $ue significa $uanto da largura de %anda 3
89
alocada para o servio durante o seu tempo ativo.
( durao do servio no caso el6stico depende do taman/o do canal atri%u-do a ele e do atri%uto
T(&(2YO. O atri%uto T(&(2YO 3 uma vari6vel de valor a partir de fun+es de distri%uio $ue
contem a $uantidade de %its do servio de Dados.
O servio 3 processado no servidor 7%loco &rocess< atendendo uma fila de pacote de acordo
com o protocolo de enfileiramento F'FO. 2a fila de um Knico servidor /6 o tipo de servio &5F5;
F'FO ou prioridade #ead4of4)ine 7F'FO em cada fila individual<.
Para o tratamento de cada servio individual 7uma fatia ou pacote<# o processo continuar6 at3
$ue ten/a esgotado o seu taman/o 7convertido em tempo dividindo pelo canal< estipulado# ou at3 $ue
todo o servio ten/a sido transmitido pelo canal.
!sta maneira de converter o taman/o do servio no tempo de durao 3 indicado por sua
representao de ser independente de fatores como a velocidade com $ue um servidor envia a
informao para a rede# a velocidade de transmisso do canal# etc. Vale ressaltar $ue a durao do
servio 3 a soma do tempo de transmisso de todas as fatias $ue comp+em os tempos de espera para a
transmisso de suas fatias sucessivas.
O taman/o de cada fatia 7ou pacote< 3 uma caracter-stica de cada servio e# neste modelo de
simulao# por simplicidade# sup+e?se $ue o comprimento m3dio de servio do tr6fego el6stico
corresponde a cerca de ;II cortes# resultando em uma fatia do taman/o de MIII %its.
Por outro lado# o tr6fego stream utili,a um codec de >= A%it5s# sendo $ue o intervalo entre os
pacotes consecutivos no podem ultrapassar =I milissegundos# o taman/o da fatia ser6 de >= GA%it5sH.=I
GmsH a 98I %its.
18&81 Re#ul!ado# do modelo a$al"!i+o
Os resultados do modelo sero apresentados nesta seo. O tempo valido das simula+es foi de
;OIII segundos# e um total de ;I replica+es para cada simulao. Para o%ter o resultado final de cada
simulao temos $ue fa,er a m3dia aritm3tica das ;I replica+es. ( $uantidade de replica+es 3 uma
ferramenta importante para a converg:ncia dos resultados.
\ importante destacar $ue por estarmos utili,ando a verso de estudante do soft@are (1!2(#
algumas simula+es no foram poss-veis de e0ecutar por serem demasiadas ro%ustas# e ultrapassarem o
limite permitido de ;OI entidades. Dessa forma conseguimos simular at3 NO !rlang para este modelo de
simulao.
O volume do tr6fego influencia os re$uisitos de desempen/o. Outro fator e0tremamente
importante 3 a influencia do uso de prioridades para os servios# $ue influencia o desempen/o do
sistema. "omo o modelo anal-tico no considera a prioridade# 3 essencial usar o modelo de simulao
para notarmos a sua influencia.
(s simula+es propostas visam a an6lise do sojourn 7tempo de processamento e tempo de
servio< do tr6fego el6stico 7Dados< $uando ocorre um aumento significativo no volume do tr6fego
stream 7Vo'P<. 1eali,amos as simula+es da seguinte forma:

(< "om prioridade# variando o servio Vo'P de 8I !rlang at3 NO !rlang# sem "(".
P< Sem prioridade# variando o servio Vo'P de 8I !rlang at3 NO !rlang# sem "(".
"< 1epetimos novamente ( e P# mas com "("# e servio Vo'P fi0o em MI !rlang.
8M
(l3m das simula+es com prioridade e sem prioridade utili,ando a funo de distri%uio
e0ponencial# iremos reali,ar os mesmos processos com duas outras distri%uio. !las so# Yiper?
e0ponencial# com o o%)etivo de simular um flu0o de ra)adas no servio el6stico# e Pareto. Dessa forma
teremos dois padr+es diferentes# com e sem flu0os em ra)adas. Para isso# a $uantidade de %its gerados
pelo atri%uto T(&(2YO ir6 variar de acordo com as novas distri%ui+es gerando o flu0o em ra)ada.
Fiura &1. Workspace do (1!2(. &odelo de simulao =.
"omo ilustra a Fig. =O# os %locos do modelo permanecem com algumas modifica+es# novos
%locos foram inseridos representando os seis servios# %locos de controle e de sa-da. Por outro lado a
estrutura lgica do modelo permanece a mesma# com apenas a adio de novos atri%utos de controle.
18&818(U!ili%a$do Di#!ri5uio E9:o$e$+ial ao A!ri5u!o TAMAN=O do #er@io de Dado#
Ca#o A e -
0' 01 1' 11 2' 21 3' 31 )' )1
SemP I#>I; I#>I9 I#>>O I#>99 I#>N; I#8;9 I#8>> I#89L I#OI9 I#O>>
ComP I#>;M I#>=L I#>M; I#8=> I#8ON I#O;N I#OM> I#9NM I#LOO ;#>ON
Ta5ela ). Sa-das do servio de Dados com prioridade e sem prioridade. Variando de O em O !rlang o
volume de tr6fego do servio Vo'P. Sem prioridade 7SemP6 !odos os servios esto utili,ando a mesma
prioridade. "om prioridade 7ComP6 o servio de Dados possui uma prioridade inferior aos demais.
8N
Fiura &2. Tempo de Sojourn do servio de Dados, dado em segundos em funo a variao do
volume de tr6fego Vo'P em !rlang. 2a lin/a preta o servio de Dados est6 com prioridade e na lin/a
a,ul sem# variando de O em O !rlang o volume de tr6fego do servio Vo'P.
"omo vimos# o perfil de um tr6fego stream 3 diferente de um tr6fego el6stico. !m um am%iente
com JoS a priori,ao do tr6fego da rede 3 fundamental. ( Fig. =9 mostra o sojourn o tempo $ue leva
para um $uadro do servio de Dados c/egar ao seu destino levando em considerao $ue o servio de
Dados 3 um servio el6stico# portanto utili,a o protocolo de transporte T"P.
( lin/a preta# com prioridade# indica $ue os servios stream possuem uma prioridade maior
com relao ao el6stico# dessa forma acarretando em um aumento do throu,htput do servio de Dados.
Por outro lado# a lin/a em a,ul# sem prioridade# indica $ue todos os servios possuem a mesma
prioridade para utili,ao dos recursos. "omo podemos notar a ta0a do sojourn diminui
significativamente mesmo com NO !rlang $uando no /6 prioridade.
Ca#o C
Da mesma forma $ue as demais simula+es# a seguir encontra?se as ;I replica+es para o caso
"# MI !rlang Vo'P. O valor do "(" sem prioridade e com prioridade so os mesmos# eles so:
8L
>0 >E E0 EE ;0 ;E D0 DE =0 =E
0
0*:
0*>
0*;
0*=
<
<*:
<*>
<*;
!a)das Data Hile
!em Prioridade
Com Prioridade
(aria"$o do volume de trfego (oIP 2Erlang3
T
e
m
p
o

d
e

!
o
I
o
u
r
n

d
o

D
a
t
a

f
i
l
e

2
s
e
g
u
n
d
o
s
3
Ser@io CAC
V-deo $n demand ;8
Videoconfer:ncia ;8
V-deo "lip N
Vo'P NO
"*mera 'P 7j<
Data file 7Dados< 7jj<
Ta5ela 4. 2Kmero m60imo de servios simult*neo. O servio c*mera 'P possui um asterisco por$ue 3
um servio cont-nuo# no envolvendo par*metros como "(" e prioridade. ! o servio de Dados# 3
influenciado pelo volume do tr6fego stream.
2o asterisco# o servio "*mera 'P no possui um "(" por$ue o servio 3 cont-nuo. X6 no caso Data
file 7Dados< o servio 3 el6stico# dessa forma sempre $ue /aver recursos suficientes ser6 gerado um
novo servio.
Ta5ela ('. 1esultados das ;I replica+es e a media de cada servio. Todos os servios esto utili,ando
a mesma prioridade. (s Sa-das TipoRTa representam o tempo de sojourn dos servios# dado em
segundos. ( sa-da o*s TipoRTa so a $uantidade total de servio gerado.
"omo podemos notar# ao comparar as Ta%s. ;I e ;; vemos $ue apenas os valores do sojourn do
servio de Dados mudam. 'sso se deve principalmente dois fatores. Por$ue os servios esto usando
os mesmos intervalos entre re$uisi+es de servios# durao de servio e# fun+es de distri%ui+es nas
duas Ta%ela s. Outro fator 3 o taman/o do canal# no $ual a %anda passante 3 suficiente para $ue os
servios no se alterem ao diminuir a prioridade do servio de Dados. Por outro lado o servio de
Dados se altera# por$ue ocorre uma mudana em sua prioridade# dando preferencia de tratamento a um
tr6fego stream.
Podemos notar tam%3m $ue a $uantidade total de servios de Dados 3 o mesmo nas duas Ta%ela
s 7Ta%ela ;I e ;;<# mudando apenas o sojourn. 'sso pode ter ocorrido por$ue a diferena do sojourn#
com prioridade e sem prioridade# foi pe$uena# no sendo suficientemente grande para poder ter gerado
mais servios no intervalo de tempo $ue durou a simulao.
OI
Sem Prioridade 1 2 3 4 5 6 7 8 9 10 Mdia
Sada Vdeo On Demand_Ta D;:E*; D?C=*C D>;?*; D=;<*: =<:=*: D<E>*> D=;D*D DD<<*; D0>:*; D?EC*< DE;<*:C
obs Vdeo On Demand_Ta > < > ? > ? : : > > ?*<
Sada amera_!P_Ta <*00:: <*00:< <*00:: <*00:< <*00:: <*00:< <*00:: <*00:< <*00:: <*00:< <*00:<E
obs amera_!P_Ta <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000
Sada Da"a #i$es_Ta 0*?CE0D 0*?=DE? 0*?;DEC 0*>?<: 0*>0:>D 0*?;CEC 0*?C;=? 0*>DE:E 0*?DC= 0*>?EC= 0*>0><?<
obs Da"a #i$es_Ta <ED <DE <D: <>? <?= <?> <E? <E< <:C <;: <E<*>
Sada Video%on#_Ta ==<*<D <CC?*; <:::*: <:<0*< <0C<*E C<:*<= C=E*;; CE?*0: <:<E*; DD=*D< <<:>*?D>
obs Video%on#_Ta C <: = C C << << <0 <0 D C*;
Sada Vo!P_Ta <DC*>; <DC*:= <D=*<< <=<*0C <D;*E; <D;*C; <=<*0D <=0*EC <DC*>D <=0*DE <DC*??>
obs Vo!P_Ta E><; E?DE E>E? E?DC E?>? E>:? E>0; E?D> E?;C E>>0 E?CD*=
Sada Video %$i&s_Ta ?0E*> :C>*=E ?<?*D ?0;*?? :CC*C? :=C*C: :C?*>: :C0*:< :CE*D ?0>*<? :CC*?EC
<;= <>? <;? <?C <>C <D> <>C <ED <>: <;< <E>*E obs Video clips_Ta
Ta5ela ((. 1esultados das ;I replica+es e a media de cada servio. O servio de Dados est6 com
uma prioridade inferior aos demais servios. (s Sa-das TipoRTa representam o tempo de sojourn dos
servios# dado sem segundos. ( sa-da o*s TipoRTa so a $uantidade total de servio gerado. (o
compararmos o sojourn dos casos (# P e " c/egamos na seguinte ta%ela.
"asos Sojourn
"aso (# com prioridade# sem "(" I#OM>
"aso P# sem prioridade# sem "(" I#8>>
"aso "# sem prioridade# com "(" I#8I8
"aso "# com prioridade# com "(" I#8LM
Ta5ela (&. "omparao do sojourn caso (#P e " do servio de Dados# distri%uio e0ponencial.
"omo esperado# em todos os casos o tempo de sojourn do servio de Dados diminui ao
aplicarmos "(" no tr6fego stream. X6 com a priori,ao do tr6fego# o sojourn do tr6fego el6stico
aumenta# por$ue a prioridade utili,ada favorece tr6fegos stream.
18&818& U!ili%a$do Di#!ri5uio =i:er>e9:o$e$+ial ao A!ri5u!o TAMAN=O do #er@io de Dado#
"omo )6 mencionado# mudamos a funo de distri%uio e0ponencial para /iper?e0ponencial do
servio de Dados afim de simular um tr6fego el6stico com ra)adas. Dessa forma os taman/os dos
$uadros tero um comprimento diferente# variando os tempos necess6rio de processamento mais o de
transfer:ncia 7sojourn<. Para um fator de comparao# reali,amos as simula+es seguindo os mesmos
casos (# P e "# para MI !rlang.
O;
om Prioridade 1 2 3 4 5 6 7 8 9 10 Mdia
Sada Vdeo On Demand_Ta D;:E*; D?C=*C D>;?*; D=;<*: =<:=*: D<E>*> D=;D*D DD<<*; D0>:*; D?EC*< DE;<*:C
obs Vdeo On Demand_Ta > < > ? > ? : : > > ?*<
Sada amera_!P_Ta <*00:: <*00:< <*00:: <*00:< <*00:: <*00:< <*00:: <*00:< <*00:: <*00:< <*00:<E
obs amera_!P_Ta <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000 <>0000
Sada Da"a #i$es_Ta 0*>=CC= 0*>D:=D 0*>>C: 0*E?EDC 0*>C0>< 0*>E?E: 0*>C?:: 0*ED=0E 0*>D?E= 0*E?DC: 0*>CD>E>
obs Da"a #i$es_Ta <ED <DE <D: <>? <?= <?> <E? <E< <:C <;: <E<*>
Sada Video%on#_Ta ==<*<; <CC?*; <:::*: <:<0*< <0C<*E C<:*<= C=E*;D CE?*0: <:<E*; DD=*D< <<:>*?D>
obs Video%on#_Ta C <: = C C << << <0 <0 D C*;
Sada Vo!P_Ta <DC*>? <DC*:C <D=*<< <=:*0C <D;*E; <D;*C; <=<*0D <=0*EC <DC*>D <=0*DE <DC*>?:
obs Vo!P_Ta E><; E?D; E>E? E?DC E?>: E>:? E>0; E?D> E?;C E>>0 E?CD*=
Sada Video %$i&s_Ta ?0E*> :C>*=E ?<?*D ?0;*?? :CC*C? :=C*C: :C?*>? :C0*:< :CE*D ?0>*<: :CC*:EC
<;= <>? <;? <?C <>C <D> <>C <ED <>: <;< <E>*E obs Video clips_Ta
"asos Sojourn
"aso (# com prioridade# sem "(" I#9IL
"aso P# sem prioridade# sem "(" I#88M
"aso "# sem prioridade# com "(" I#8;8
"aso "# com prioridade# com "(" I#O;O
Ta5ela (/. "omparao do sojourn caso (#P e " do servio de Dados# distri%uio /iper?e0ponencial.
Os resultados para todos os casos foram maiores# comparado aos da Ta%. ;=# por utili,armos
flu0o em ra)ada. ( e0press+es $ue utili,amos para gerar a $uantidade de %its $ue o $uadro possui 3
dada por
f ( 2)=\
;
e
\
;
2
;
+\
=
e
\
=
2
=
, 7;L<
onde
\
;
=;/ (>=IIIN)
#
2
;
=>=IIIN
#
\
=
=;/(=IO>>IN)
#
2
=
==IO>>IN
. Dessa forma
conseguirmos simular um flu0o em ra)adas com uma m3dia pr0ima aos valores $ue a distri%uio
e0ponencial gera.
18&818/ U!ili%a$do Di#!ri5uio Pare!o ao A!ri5u!o TAMAN=O do #er@io de Dado#
Para simularmos a distri%uio Pareto utili,amos sua e0presso no formato e0ponencial G>;H#

= =log(
>
2
m
) ,
7=I<
onde 2m 3 o valor m-nimo da distri%uio. Se = segue uma e0ponencial de m3dia ;5#
2
m
. e
=
, 7=;<
segue uma distri%uio de pareto de m3dia | 2=N8IIIN 7valor da m3dia do servio de Dados<.
Fa,endo 2m a ;# temos o= | 2 /( | 2;)=N8IIIN/(N8IIN;)=;#IIIII;8NNILMO .
Ve)a $ue mudam os valores das distri%ui+es dos taman/os dos servios de Dados mas no
muda a m3dia 7$ue deve continuar a ser N8III0N %its<. 2a verdade# a distri%uio de Pareto# $ue 3 de
cauda longa# nesse caso no vai provocar ra)adas# mas vai provocar varia+es mais acentuadas nos
taman/os servios de Dados. !ssas varia+es no taman/o tam%3m aca%am provocando ra)adas. (
distri%uio de cauda longa provocaria ra)adas se estivesse no processo de c/egadas 7no entanto# o
processo de servio pode provocar maior varia%ilidade no tempo de atendimento e no taman/o da fila<.

O=
"asos Sojourn
"aso (# com prioridade# sem "(" I#II;NM>
"aso P# sem prioridade# sem "(" I#II;N;9
"aso "# sem prioridade# com "(" I#II;NIL
"aso "# com prioridade# com "(" I#II;N9I
Ta5ela (0: "omparao do sojourn caso (#P e " do servio de Dados# distri%uio Pareto. tili,ando
MI !rlang.
18/ Modelo de Simulao /
O modelo de simulao > 3 uma continuao do modelo =. Tanto os %locos como seus valores
so os mesmos apresentados no modelo =. Dessa forma o modelo anal-tico permanece o mesmo. (
diferena entre os dois modelos 3 $ue o modelo > simula um am%iente VP2.
ma Virtual &rivate "et.ork 7VP2< 3 uma forma segura de se conectar a uma rede privada
atrav3s de um local remoto# utili,ando a internet ou uma rede pK%lica insegura para transportar os
pacotes utili,ando criptografia. O VP2 3 fre$uentemente utili,ado por usu6rios remotos ou empresas
$ue $uerem compartil/ar informa+es e recursos de um mesmo am%iente de rede.
"omo o VP2 foi desenvolvido para acesso a redes remotas# a distancia entre os dois ns podem
acarretar em mKltiplos saltos entre roteadores# e meios f-sicos diferentes# at3 c/egar ao seu destino.
!sses fatores vo influenciar o JoS do sistema diretamente. Pro%lemas de propagao# como jitter#
lat:ncia e perda# $ue em uma rede local privada no c/ega a pre)udicar a comunicao# por serem
valores pe$uenos# agora# em um am%iente VP2 podem aumentar muito o tempo de transfer:ncia de um
ar$uivo ou at3 mesmo impedir a utili,ao de servios.
Podemos reali,ar um teste simples utili,ando a ferramenta ZTrace Router[ do Cindo@s para
identificar o tempo de propagao gasto entre dois pontos distintos no glo%o e o tempo de propagao
dentro de uma rede local. !ssa ferramenta mostra todos os saltos e# tempo de propagao total
necess6rio para $ue o pacote c/egue ao seu destino. Para demonstrao utili,aremos dois sites# um no
Prasil# e outro na 1Kssia.
( figura a seguir mostra os ;= saltos necess6rios at3 $ue o pacote c/egue ao seu destino# o
servidor da O.. O primeiro salto 3 o roteador interno da .(2# portanto 3 uma rede interna privada.
Podemos notar a diferena de tempo $ue leva o primeiro salto com os demais# sendo os demais saltos
foram reali,ados na C(2. Por meio deste e0emplo simples podemos notar a influencia do jitter#
lat:ncia e perda de pacotes ao compararmos as > colunas $ue representam o tempo gasto em cada salto.
O>
Fiura &3. Trace Router do site @@@.uol.com.%r.
O tempo total de propagao para o site da O. foi de =98 ms. m tempo normal utili,ando o
protocolo T"P5'P. X6 o site russo# @@@.%;.rs# levou ;NIO ms# sendo preciso passar por ;> saltos#
utili,ando T"P5'P. m tempo como esse para tr6fegos do tipo el6stico# como a aplicao YTTP 3
aceit6vel. &as se isso ocorrer a um tr6fego stream# podemos ter pro%lemas de degradao do servio ou
a impossi%ilidade de esta%elecimento de cone0o por falta de condi+es m-nimas e0igidas pelo servio.
Fiura &). Trace Router do site @@@.%;.rs.
O8
18/8( Re#ul!ado#
Para implementar o modelo de simulao a fim de simular um am%iente VP2 utili,amos tr:s
atri%utos novos nos seis servios )6 con/ecidos. !les so# +itter# Perda# e (traso# sendo o (traso o
atri%uto respons6vel a simular a lat:ncia. "omo o soft@are (1!2( utili,ado 3 a verso estudante#
neste modelo de simulao tivemos a inconveni:ncia do limite de entidade# no permitindo simula+es
acima de MI !rlang.
"onforme ilustrado no e0emplo do ZTrace Router[ o jitter mais a lat:ncia resultam no tempo
total de atraso do pacote. Dessa forma# conseguimos simul6?los adicionando um tempo e0tra $ue
levaria o pacote para c/egar ao seu destino. O atri%uto perda representa uma porcentagem de perda $ue
pode ocorrer a cada pacote transmitido no VP2.
Os valores do jitter# lat:ncia e perda foram sugeridos a partir de diversas referencias G>=# >># >8
>OH. (s Ta%s. ;O# ;9 e ;M a seguir se encontram os valores de cada atri%uto por servio. Propus3mos
tr:s diferentes valores para o servio de Dados mantendo os valores dos outros servios.
Videoconfer
:ncia
V-deo $n
(emand
V-deo Clip Vo'P "*mera 'P Data file
7Dados<
+itter M;I
>
M;I
>
M;I
>
;II;I
>
M;I
>
N;I
>
(traso I#I> I#; I#;
8II;I
>
I#I>
9I;I
>
Perda
;I
O
;I
O
;I
O
I#IO
;I
O
;I
L
Ta5ela (1. Valores dos atri%utos +itter e (traso em segundos# e Perda em porcentagem# dos seis
servios do modelo.
Videoconfer
:ncia
V-deo $n
(emand
7Dados<
+itter M;I
>
M;I
>
M;I
>
;II;I
>
M;I
>
N;I
>
(traso I#I> I#; I#;
8II;I
>
I#I>
9I;I
>
Perda
;I
O
;I
O
;I
O
I#IO
;I
O
I#I;
servios do modelo.
Videoconfer
:ncia
V-deo $n
(emand
7Dados<
+itter M;I
>
M;I
>
M;I
>
;II;I
>
M;I
>
;9;I
>
(traso I#I> I#; I#;
8II;I
>
I#I>
9I;I
>
Perda
;I
O
;I
O
;I
O
I#IO
;I
O
;I
L
servios do modelo.
OO
(l3m da mudana dos atri%utos# reali,aremos# como no modelo =# simula+es para os casos (#P
e "# para as fun+es de distri%uio e0ponencial# /iper?e0ponencial e pareto. 2a representao a seguir
entenderemos mel/or todos os casos propostos.
Funo de Distri%uio !0ponencial
tili,aremos os valores dos atri%utos da Ta%. ;O para reali,ar os casos:
"aso (# com prioridade# sem "("
"aso P# sem prioridade# sem "("
"aso "# sem prioridade# com "("
"aso "# com prioridade# com "("
tili,aremos os valores dos atri%utos da Ta%. ;9 para reali,ar os casos:
tili,aremos os valores dos atri%utos da Ta%. ;M para reali,ar os casos:
Funo de Distri%uio Yiper?e0ponencial
Funo de Distri%uio Pareto
O9
Funo de Distri%uio Pareto Truncada
( funo de distri%uio de Pareto truncada cont:m um fator de correo# $ue segundo a
refer:ncia G>LH dependendo do nKmero de d-gitos do processador da m6$uina utili,ado nas simula+es
deve?se utili,ar um determinado fator de correo. ( gerao da distri%uio Pareto est6 correta# mas
pelas caracter-sticas de cauda longa# ela aca%a sendo influenciada pelos d-gitos de preciso da m6$uina
e aca%a na forma de distri%uio truncada. De G>LH# o valor do fator multiplicativo para 98 %its
7m6$uina utili,ada para as simula+es< resultou em torno de ;O;OI.
7==<
2os casos ( e P temos um volume de tr6fego no servio Vo'P 78I# OO e MI !rlang<# e para o
caso " fi0o em MI !rlang. Foram simuladas O replica+es por simulao e um per-odo de ;9III
segundos por replicao. "om O replica+es conseguimos uma preciso do resultados em torno de Md
para tr6fegos el6sticos e >d para tr6fegos stream.
OM
Fu$o de Di#!ri5uio E9:o$e$+ial
1esultados o%tidos utili,ando os valores da Ta%. ;O.
Ta5ela (): Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela (4. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
1esultados o%tidos utili,ando os valores da Ta%. ;9.
Ta5ela &'. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela &(. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
1esultados o%tidos utili,ando os valores da Ta%. ;M.
Ta5ela &&. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela &/. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
Fu$o de Di#!ri5uio =i:er>e9:o$e$+ial
ON
>0 EE D0
Caso % E*?DED: E*?CC: E*>>>C;
Caso & E*>::<> E*?C>>: E*=:0D
D0
Caso C P< E*>;?==
Caso C P: E*>E?:=
>0 EE D0
Caso % E*>DDD> ;*00<0> E*DC:>:
Caso & E*=E0;= E*><E== E*;?D>;
D0
Caso C P< E*?=?:
Caso C P: E*=>:;;
>0 EE D0
Caso % E*>E=C; E*EC?: E*:;<>:
Caso & E*C;D== E*><<0; E*;<D<>
D0
Caso C P< E*E?DD
Caso C P: E*?=>E>
Ta5ela &1. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
Ta5ela &). Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Fu$o de Di#!ri5uio Pare!o
Ta5ela /'. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela /(. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
OL
>0 EE D0
Caso % <0*:C0:> <0*:>C <0*<0<E;
Caso & <<*0CE> <0*EE=C> <0*0?<D>
D0
Caso C P< <0*=;:>=
Caso C P: C*?C;==;
>0 EE D0
Caso % <0*>:>? <0*EC=>; <0*>;=:>
Caso & C*C<?< <0*?CD=> <0*?:C=:
D0
Caso C P< <0*;0:C=
Caso C P: <0*E<<>;
>0 EE D0
Caso % <0*<?<E; <0*>C<C> <0*<0D==
Caso & <0*D>>= C*=C< <0*ED=;:
D0
Caso C P< <0*0=EE
Caso C P: <0*<==E:
>0 EE D0
Caso % 0*00<D=: 0*00<D=: 0*00<D=
Caso & 0*00<DD= 0*00<D= 0*00<DD;
D0
Caso C P< 0*00<D;>
Caso C P: 0*00<D;>
Ta5ela /&. Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela //. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
Ta5ela /1. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
Fu$o de Di#!ri5uio Pare!o Tru$+ada
Ta5ela /). Tempo Sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
9I
>0 EE D0
Caso % 0*00::D; 0*00:E: 0*00:<>:
Caso & 0*00::D: 0*00:E<; 0*00:0E;
D0
Caso C P< 0*00:EC=
Caso C P: 0*00:EC=
>0 EE D0
Caso % 0*00<D=: 0*00<D=: 0*00<D=
Caso & 0*00<DD= 0*00<D= 0*00<DD;
D0
Caso C P< 0*00<D;>
Caso C P: 0*00<D;>
>0 EE D0
Caso % 0*=<>?; <*0EEC: <*>>?:D
Caso & 0*=DCD;? <*0;===? 0*=C;0:?
D0
C P< <*<=;;DD
C P: 0*=>?D=?
>0 EE D0
Caso % 0*=0<?0? <*=C0:C :*>E=>:?
Caso & <*D?:0?? :*:E<<CD <*<D=<<<
Ta5ela 0'. Tempo sojourn do servio de Dados# caso ( com prioridade# caso P sem prioridade.
Ta5ela 0(. Tempo Sojourn do servio de Dados# P; a sem prioridade# P= a com prioridade.
18/8& Com:arao do# Re#ul!ado#
Faremos duas compara+es# entre os resultados dos casos de uma mesma distri%uio# e em
seguida entre as distri%ui+es.
Di#!ri5uio E9:o$e$+ial
Fiura &4. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
9;
>0 EE D0
>*=
E
E*:
E*>
E*;
E*=
;
;*:
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

d
e

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
D0
C P< <*<<0D;
C P: <*<;:C?
>0 EE D0
Caso % 0*D?E=DD 0*D==CDD 0*=D0=>
Caso & 0*DD;DED 0*C:?D;? 0*D>E0ED
D0
C P< 0*;E?;>D
C P: 0*;0D=DD
2o caso e0ponencial o comportamento dos resultados com prioridade 7caso (<# Fig. =L# e sem
prioridade 7caso P<# Fig. >I# tiveram uma mudana %rusca de comportamento# principalmente# nas
lin/as amarela e vermel/a# mas elas esto seguindo uma mesma tendencia de comportamento. ( m3dia
do sojourn do caso ( e P permaneceram pr0imas mesmo mudando suas prioridades.
Fiura /'. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
Di#!ri5uio =i:er>E9:o$e$+ial
Fiura /(. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
9=
>0 EE D0
E*<
E*:
E*?
E*>
E*E
E*;
E*D
E*=
E*C
;
;*<
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n
2
s
e
g
u
n
d
o
s
3
>0 EE D0
C*=
C*C
<0
<0*<
<0*:
<0*?
<0*>
<0*E
<0*;
<0*D
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
"om a adio dos atri%utos jitter e lat:ncia tivemos resultados com comportamentos diferentes
dos vistos no modelo de simulao =. "omo mostra a Fig. >; e >=# nem sempre ao aumentarmos o
volume do tr6fego Vo'P 78I# OO e MI !rlang< temos um aumento do tempo sojourn do servio de
Dados.
Fiura /&. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
Di#!ri5uio Pare!o
Fiura //. Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
9>
>0 EE D0
C*:
C*>
C*;
C*=
<0
<0*:
<0*>
<0*;
<0*=
<<
<<*:
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
>0 EE D0
0*0000
0*000E
0*00<0
0*00<E
0*00:0
0*00:E
0*00?0
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
( distri%uio de Pareto foi a $ue mais se apro0imou de um padro de comportamento ao
simularmos caso ( e P. Podemos nota?lo nas Fig. >> e >8.
Di#!ri5uio Pare!o Tru$+ada
98
>0 EE D0
0*0000
0*000E
0*00<0
0*00<E
0*00:0
0*00:E
0*00?0
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
>0 EE D0
0
0*E
<
<*E
:
:*E
?
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
Com:arao e$!re fu$;e# de di#!ri5uio
tr6fego em !rlang. "omparao dos casos ( entre a distri%uio e0ponencial e /iper?e0ponencial.
Ve)a $ue mudam os valores do tempo de sojourn dos servios de Dados# na Fig. >O e >9# ao
cam%iarmos as fun+es de distri%ui+es# mas no mudam as tendencias de comportamento das lin/as.
2a Fig. >O# nas duas distri%ui+es ao termos OO !rlang ocorre um pe$ueno aumento no tempo sojourn.
O efeito contrario ocorre na Fig. >9# diminuindo o tempo de sojourn.
9O
>0 EE D0
0
:
>
;
=
<0
<:
E'p
Jiper
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
>0 EE D0
0
0*E
<
<*E
:
:*E
Ta/1 <E
Ta/1 <;
Ta/1 <D
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
Fiura /). Tempo de sojourn do servio de Dados# em segundos# em funo a variao do volume do
tr6fego em !rlang. "omparao dos casos P entre a distri%uio e0ponencial e /iper?e0ponencial.

99
>0 EE D0
0
:
>
;
=
<0
<:
E'p
Jiper
(aria"$o em Erlang
T
e
m
p
o

!
o
I
o
u
r
n

2
s
e
g
u
n
d
o
s
3
28 Co$+lu#;e#
2esse tra%al/o foi discutido um con)unto de modelo anal-tico# simula+es e emula+es
e$uacionando a $uesto do dimensionamento do enlace. Juando se trata de um enlace onde se tem o
controle de suas condi+es de tr6fego 7ou se pode fa,er medidas<# o modelo anal-tico e simula+es
satisfa,em s necessidades. Juando 3 necess6rio estimar outros par*metros# como em um VP2# o
gerador de tr6fego5emulador tem um papel fundamental por$ue possui a influencia do canal resultando
em resultados pr0imos de um am%iente real.
&uitos desafios surgiram durante o desenvolvimento das atividades desta dissertao# como o
gerador de tr6fegos multim-dia e os modelos de simulao. (s emula+es feitas utili,ando socket
mostrou?se fieis aos resultados o%tidos utili,ando as mesmas configura+es no (1!2(. ( $uantidade
de servios gerados no emulador so $uase sempre menores ao do (1!2( pelo fato do arena ser
simulado localmente# no transmitindo os pacotes atrav3s de um meio f-sico.
Para um aprimoramento no gerador foi sugerido a implementao da pil/a T"P5'P u'P para
termos controle do header 'P. 2o header 'P e0iste campos de identificao do servio $ue o pacote
pertence# e sem esta manipulao no conseguimos fa,er um tratamento de identificao na camada de
rede# tendo $ue ser feito na camada de transporte utili,ando a identificao de cada servios em suas
respectivas portas. !ssa implementao 3 fundamental para aumentar a agilidade do tr6fego dos pacotes
nos roteadores $ue tratam o tr6fego com priori,ao# mel/orando o JoS da rede evitando filas. Foram
feitas implementa+es na pil/a T"P5'P u'P com o o%)etivo de aprimorar a pil/a e adapta?la para a
integrao com o emulador de tr6fegos multim-dia. 'nfeli,mente aps as implementa+es feitas no u'P
estarem completas# desco%rimos a incapacidade de utili,ao do u'P# por no possuir um driver. Sem
um driver a pil/a no consegue se comunicar com a interface da placa de rede# impossi%ilitando $ue os
pacotes se)am transmitidos atrav3s do meio f-sico. ( implementao de um driver para a pil/a foi
descartado pelo tempo $ue levaria para o seu desenvolvimento e testes de confia%ilidade. Por outro
lado# a utili,ao da interface T25T(P mostrou?se insegura# mesmo o u'P possuindo uma funo
para o seu uso# o T25T(P no transmitiu nen/um %it das aplica+es de e0emplo $ue o u'P possui.
Foram propostos tr:s diferentes modelos de simulao $ue simulam am%ientes multim-dia# onde
servios stream e el6stico so re$uisitados ao mesmo tempo pelos usu6rios. ( funo de um modelo 3
descrever o funcionamento da realidade atrav3s de um pe$ueno nKmero de vari6veis $ue permita a sua
converso. O modelo ; possui tr:s %locos Arrive# $ue so os respons6veis pela gerao dos servios
stream# videoconfer:ncia# v-deo?clip# e v-deo on demand! "ada %loco possui valores $ue representam
seus servios e fun+es de distri%uio. Para cada servio /6 duas sa-das# servios re)eitados e servios
completados. O modelo = e > possuem seis servios# videoconfer:ncia# v-deo?clips# v-deo on demand,
Vo'P, c*mera 'P# e data file 7servio de Dados<# sendo apenas o servio de Dados do tipo el6stico!
2o modelo ; foram reali,ados simula+es propondo um estudo de demanda dos usu6rios# onde
tr:s cen6rios foram estudados. !sses tipos de situa+es so amplamente estudadas em casos de
mudana do comportamento na tarifao das empresas de telefonias moveis e fi0a# onde a co%rana no
3 mais feita por minutos utili,ados# mas sim por c/amadas feitas aumentando significativamente a
durao das c/amadas. Os estudos de demanda so cruciais por parte das empresas para no acarretar
em um %ai0o JoS 7infringindo as regras da (2(T!.< e %lo$ueios de c/amadas elevado. Dos
resultados o%tidos nas Figs. == e => podemos notar $ue mesmo /avendo um aumento %rusco no tempo
m3dio da durao das c/amadas ou# no intervalo m3dio entre as re$uisi+es 3 poss-vel ter uma margem
aceit6vel de JoS em am%ientes em $ue ocorram picos proporcionando recursos um pouco acima da
m3dia.
9M
2o modelo = ficou claro a import*ncia da priori,ao dos servios# por$ue o perfil de um
tr6fego stream 3 diferente de um tr6fego el6stico. !m um am%iente com JoS a priori,ao do tr6fego
da rede 3 fundamental. 2a simulao da Fig. =9# podemos notar com clare,a a diferena do sojourn
$uando se utili,a priori,ao dos servios# o tempo $ue o pacote el6stico demorou para c/egar ao seu
destino# com um volume de tr6fego de NO !rlang# foi =#O8 ve,es maior $uando a prioridade do servio
de Dados 3 inferior aos demais# aumentando o tempo de entrega dos pacotes el6stico.
2o modelo > os par*metros do jitter e da lat:ncia mudaram significativamente o
comportamento do sojourn visto no modelo =. !m todos os cen6rios simulados no modelo > /ouve um
aumento significativo no tempo de sojourn. (l3m disso# mesmo aumentando o volume do tr6fego
stream# o tempo de sojourn do tr6fego el6stico em muitos casos no aumentou. 'sso se deve pela
influencia do jitter e da lat:ncia em am%ientes VP2. 2os e0emplos utili,ando o Trace Router foi
poss-vel notar a influ:ncia do jitter e da lat:ncia em um am%iente real# em $ue a variao do tempo $ue
leva para o pacote c/egar ao seu destino passando pelos mesmos meios f-sicos nem sempre so as
mesmas. "omo as simula+es e o Trace Router mostraram# estamos sempre vulner6veis aos pro%lemas
de jitter e de lat:ncia# resultando em tempos de sojourn inesperados.
!m tra%al/os futuros o estudo da su%stituio do socAet da pil/a T"P5'P 3 fundamental. ( pil/a
u'P estudada nesse tra%al/o mostrou $ue apesar de ser uma pil/a compacta e possuir o perfil $ue
dese)amos# como ser cdigo a%erto em " e desenvolvida para .inu0# ela possui alguns pro%lemas $ue
precisam ser contornados para $ue se)a poss-vel utili,a?la# como o driver e a agilidade do *uffer.
Simula+es utili,ando a verso completa do soft@are (1!2( proporcionar6 futuros estudos com
volumes de tr6fegos diferentes e com v6rias replica+es dos modelos propostos. &uitos casos
importantes no foi poss-vel simular devido as op+es restritas $ue a verso de estudante do (1!2(
proporciona.
9N
ReferB$+ia#
G;H Fartner 'nc. "arina Forsling. World.ide Consumer 5road*and &enetration Sees Rapid %ro.th *ut
Current &rice Strate,y Alone is "ot Sustaina*le for Telecom Carriers Says %artner!
/ttp:55@@@.gartner.com5it5page.)spkidaOI;=M9
G=H 'nternetional Television !0pert Froup. 'T!F.org.
/ttp:55@@@.international?television.org5tvRmarAetRdata5glo%al?iptv?forecast?=IIL?=I;>./tml
G>H &ediaroom# Pro)eto envolvendo diversas empresas# como &icrosoft# (TWT# PT Vision# DT e muito
outras. /ttp:55@@@.microsoft.com5&ediaroom5default.asp0
G8H 2oAia Siemens 2et@orA. Solu+es para 'PTV.
/ttp:55@@@.noAiasiemensnet@orAs.com5portfolio5solutions5iptv?is?Bour?opportunitB?to?en/ance?
revenue
GOH ( . Folaup e Y. (g/vami# A multimedia traffic modelin, frame.ork for simulation *ased
performance evaluetion studies# "omputer 2et@orAs OI =IM; 7=II9<.
G9H C.!. .eland# &.S. Ta$$u# C. Cillinger# D.V. Cilson# $n the self4similar nature of thernet traffic
9e2tended version)# '!!!5("& Trans. 2et@orAing = 7;< 7;LL8< ;c;8
GMH (. Folaup# (.Y. (g/vami# /odelin, of /&%? traffic at %o& level usin, autore,ressive processes#
'!!! Ve/. Tec/nol. "onference Fall =II=# Vancouver# Pritis/ "olum%ia#
"anada# =II=# pp. NO8cNON.
GNH F.Y.P. Fit,eA# &. 1eisslein# /&%4? and #!@AB video traces for net.ork performance evaluation#
1eport no. TE2?II?I9# Tec/nical niversitB Perlin# Perlin# Octo%er =III.
GLH ( . .a,aris# P. EoutsaAis e &. PateraAis# A ne. model for video traffic ori,inatin, from multiple2ed
/&%4? videoconference streams# Performance !valuation 9O O; 7=IIN<.
G;IH &.C. Farrett# C. Cillinger# (nalBsis# &odelin, and ,eneration of self4similar V5R video traffic#
in: Proceedings of ("& S'F"O&&L8# pp. =9Lc=NI.
G;;H S. &a# ". Xi.# /odelin, video traffic in the .avelet domain# in: Proceedings of '2FO"O&LN# San
Francisco# "(# vol. ;# ;LLN# pp. =I;c=IN
G;=H S. ( . (lJa/tani# A Simulation45ased Comparison of /ultimedia Traffic &rioriti7ation Schemes
for #i,jt4&erformance Input4<ueued &acket S.itches# X. "omputer Sci. = 78< 7=II9<
G;>H P.! @irt/# The role od teletraffic modelin, in the ne. communication paradi,ms# I comum.
&ag. 7;LLM< N9?L=.
G;8H V.S. Frost# P. &elamed# Traffic modelin, for telecommunications net.ork, I comum. &ag.
9L
7;LL8< MI?N;.
G;OH liv (# Colpe P1# Small SD# %lick S! Simulation4*ased medical education6 an ethical imperative.
(cad &ed =II>g MN7N< :MN>? N.
G;9H &(2OV'"Y# .ev# 'mage Future# Outu%ro de =II># editado em (%ril de =II8# revisto em =II9
G;MH (. Folaup# (.Y. (g/vami# &odeling of &P!F8 traffic at FoP level using autoregressive
processes# '!!! Ve/. Tec/nol. "onference Fall =II=# Vancouver# Pritis/ "olum%ia# "anada# =II=#
pp. NO8cNON.
G;NH (rena F(J# /ttp:55@@@.arenasimulation.com5ToolsR1esourcesR(renaRF(Js.asp0m
G;LH C. David Eelton# 1andall P. Sado@sAi# David T. SturrocA# C. Eelton# 1andall Sado@sAi# David
SturrocA. Simulation .ith Arena! >rd edition# =II>.

G=IH .eandro (gugliari# Tito 1icardo Pianc/in Oliveira. Desenvolvimento de um gerador de tr6fego
multim-dia. TF' apresentado Faculdade de Tecnologia c FT c 2'"(&P.
G=;H "(1V!1# 1ic/ard Y.g T('# Euo?"/ung. /odern /ultithreadin,6 Implementin,, Testin, and
(e*u,,in, /ultithreaded +ava and CCCD&threadsDWinB@ &ro,rams. !ditora CileB. Outu%ro =IIO.
G==H (dam DunAels. T/e u'P !m%edded T"P5'P StacA. T/e u'P ;.I 1eference &anual. ip?refman.
G=>H .i FranA hong# Stol 2orvald. A priority4oriented call admission control paradi,m .ith <oS re4
ne,otiation for multimedia services in -/TS. '!!! O>rd Ve/icular Tec/nologB "onference# Freece#
=II;# vol.># =I=;c=I=O.
G=8H Fonte %i%liogr6fica da Figura5Ta%ela : (ndre@ Stuart Tanen%aum# Computer "et.orks!
G=OH Jualidade de Servio 7JoS< em 1edes 'P Princ-pios P6sicos# Par*metros e &ecanismos# Prof.
Yugo Santana# niversidade Santa "ec-lia c nisanta.
G=9H S. &. ". TO&!# !. .. 1S'2'# 2. &'2"OV# Dimensionamento de 1ede 'P 'ntegrada
"orporativa5Operativa de Su%esta+es de !nergia# ' "ongresso Tecnolgico 'nfo%rasil# Fortale,a# "!#
=IIN.
G=MH 1... S/arma# "et.ork (esi,n -sin, co"ets# 'nternational T/omson "omputer Press# Poston#
;LLM.
G=NH &.P. Trindade# &.S. &edrano# (.". .avel/a# Plane)amento de !nlaces 'P &ulti?servio#
considerando 1e$uisitos de JoS# "ongresso 2acional de Tecnologia da 'nformao e "omunicao c
S"!S =II># Salvador# =II>
G=LH (. 1iedl# T. Pausc/ert and (. Pro%st# (imensionin, of I& access net.orks .ith elastic traffic#
2!TCO1ES =III# Proceedings# Toronto# =III.
MI
G>IH X.F.P. .a%ourdette e F.C. Yart# 5lockin, &ro*a*ilities in /ultitraffic )oss Systems6 Insensitivity,
Asymptotic 5ehavior and Appro2imations, I Transactions on Communications, v! ?E, n! F, a,o!
GHH@
G>;H /ttp:55en.@iAipedia.org5@iAi5ParetoRdistri%ution
G>=H (catel# Futurecom de =II;.
G>>H Eurose: 1ede de "omputadores e a 'nternet# Xames F. Eurose e Eeit/ C. 1oss# terceira edio.
G>8H Xorge &oreira de Sou,a# JoS para Vo'P '.
G>OH Prof. Dr. Valter 1oesler# F1FS# (n6lises e &edida de Desempen/o em 1edes .ocais.
G>9H /ttp:55vtun.sourceforge.net5tun5
G>MH Fernando .. Pinotti# Tito Oliveira# Varese Timteo# !dson rsini# (n 'P?%ased multimedia traffic
generator# Proceeding 'CT =I;;# 'SS2 ;NI9?M99=.
G>NH Dalila Fonseca# Deolinda Pac/eco# Fernando &ar$ues# 1icardo Soares# Porto !ditora# (plica+es
inform6ticas (# =II9# Porto.
G>LH Accelerated Simulation of &o.er4)a. Traffic in &acket "et.orks# Yo ' &a# (epartment of
lectronic n,ineerin, <ueen /ary -niversity of )ondon, Septem*er @EEB!
M;
APGNDICE A> ARENAH PROGRAMA DE SIMULAIJO
O (1!2( ;=.I 7verso educacional< utili,ado neste tra%al/o 3 um soft@are de simulao por
eventos discretos. !le 3 composto de uma interface gr6fica onde os principais componentes para gerar
as simula+es# so os mdulos configura dos de acordo com a funcionalidade dos mesmos.
Fiura /4. Tela principal do (1!2(.
(o final de cada simulao o (1!2( gera um relatrio da simulao# o%servando o
comportamento das vari6veis definidas em um ar$uivo de e0tenso.out.
O (1!2( ;=.I disp+em de mdulos simples# $ue reali,am apenas uma funo# e mdulos
compostos# $ue so um con)unto de fun+es em um mesmo mdulo# afim de simplificar as simula+es
$ue re$uerem um nKmero elevado de entidades. !m nossos modelos foram usados os dois tipos de
mdulos.

M=
DESCRIIJO DOS -LOCOS UTILIKADOS
(s informa+es a$ui presentes foram o%tidas atrav3s do #elp do (1!2(.
-lo+o A''%()
O mdulo Arrive# presente no painel Common# 3 usado para gerar as entidades $ue c/egam a
um modelo. ( partir dele# so criadas as entidades# individualmente ou em lotes. 2o nosso modelo
utili,amos seis %locos Arrive# cada um deles representando a gerao de um servio Knico. !les so
cinco servio do tipo stream# Videoconfer:ncia# V-deo "lip# "*mera 'P# Video on (emand# VoI&, e um
servio do tipo el6stico# (ata files 7Dados<.
M>
Fiura 0'. Par*metros do %loco ARRIV!
nter (ata
Station: !ste campo define o nome da estao associada a este mdulo.
Arrival (ata
5atch Si7e6 !ste campo define o nKmero de entidades em cada lote.
Iirst Creation: 'nstante# a partir do $ual# a primeira entidade pode ser criada.
Time 5et.een: !ste campo define o tempo entre cada criao de entidade 7ou lote de entidades<.
Podem ser utili,adas fun+es de distri%uio para definir este valor# como destaca a figura .
/ark Time attri*ute6 !specifica o nome do atri%uto da entidade# utili,ado para determinar o
tempo de sistema.
)eave (ata
Station: !ste campo especifica a estao para a $ual a entidade 3 transferida.
Route Time: !ste campo define o tempo $ue uma entidade gasta para ir de uma estao a outra.
-lo+o )*T)'
!ste mdulo define uma estao 7ou um con)unto de esta+es< correspondendo a um local f-sico
ou lgico onde ocorrem opera+es. Se o mdulo nter definir um con)unto de esta+es# ele define os
locais de mKltiplos processamentos. ma entidade pode se mover de um mdulo anterior para um
mdulo nter de tr:s maneiras: transferida para a estao 7ou con)unto de esta+es< associada com o
mdulo# atrav3s de uma cone0o gr6fica ou por um redirecionamento via um campo "e2t )a*el.
Juando uma entidade c/ega a um mdulo nter# pode ocorrer um tempo de descarregamento e
$ual$uer m6$uina usada para transportar a entidade 3 li%erada.
M8
Fiura 0(. Par*metros do %loco "TR!
)a*el: !ste campo define o nome do la*el $ue ser6 associado com este mdulo.
Station Type: Determina se uma Knica estao ou um con)unto de esta+es 3 usado para
identificar o ponto de entrada para este mdulo. Se o Station Set for o selecionado# significa $ue este
mdulo est6 definindo a entrada em um su%modelo com v6rias esta+es.
Station6 Define o nome da estao associada a este mdulo.
-nload6 !ste campo define o tempo $ue as entidades levam para serem descarregadas dos
transportadores.
Transfer Type6 'ndica o modo como as entidades li%eram seus meios de transporte.
-lo+o C+""S)
O mdulo choose fornece op+es de escol/a para as entidades %aseadas no condicional if#
)untamente com as regras else e al.ays. Os destinos das op+es so definidos por conectores ou por
la*els.
MO
Fiura 0&. Par*metros do %loco C#$$S!
Condition
Selection $ption: !stas op+es determinam o nKmero de entidades $ue sair6 do mdulo choose#
%aseadas nas op+es $ue sero avaliadas como verdadeiras. Selecionando?se a Take Iirst True
Condition# a entidade sair6 do mdulo Chance %aseado na primeira condio if avaliada como
verdadeira. 2en/uma cpia da entidade original ser6 criada. Take all true conditions far6 com $ue a
entidade saia da primeira condio if avaliada como verdadeira e cpias das entidades $ue c/egam
se)am criadas para cada uma das condi+es al.ays e if true restantes. Specify /a2 to take permite $ue
um nKmero m60imo e definido de op+es se)am avaliadas pelas entidades.
Condition: !ste grupo 3 usado para definir todas as poss-veis op+es $ue uma entidade pode
escol/er.
Para adicionar uma condio %asta clicar em A((# e configurar os par*metros a%ai0o:
M9
Fiura 0/. "onfigurando Conditions.
O tipo pode ser condicional 7if< ou determin-stico 7elseDal.ays<. O if re$uer a definio de uma
e0presso condicional. Somente uma opo else deve ser usada por mdulo.
Condition: !ste campo descreve a condio correspondente para cada condio if. Pode se usar
sinais lgicos ou de comparao# como: or, and# n# _#etc.
"e2t )a*el: !ste campo define o pr0imo mdulo para onde a entidade se deslocar6 se a opo
especificada for selecionada.
-lo+o ASSIGN
!ste mdulo permite a associao de um valor a uma vari6vel definida pelo usu6rio# flu0os
cont-nuos ou n-veis# atri%uto ou entidades# vari6vel de status de modelo# ou um estado de recurso.
(ssocia+es mKltiplas podem ser feitas em um Knico mdulo Assi,n. Juando uma entidade c/ega a um
mdulo Assi,n# o valor ou estado associado 3 avaliado e 3 associado a uma vari6vel ou recurso
espec-fico. Se um atri%uto ou figura 3 especificado# o atri%uto ou figura da entidade $ue c/ega 3
associado ao novo valor.
MM
Fiura 00. Par*metros do %loco ASSI%"!
"licando em dit 3 poss-vel editar as associa+es
Figura 8O: "onfigurando (ssocia+es.
MN
Assi,ment Type: 'ndica o tipo de vari6vel $ue ser6 associada.
-lo+o P'"C)SS
O mdulo &rocess 3 usado para definir uma etapa de processamento. Juando uma entidade
c/ega a um mdulo &rocess# ela espera at3 $ue um servidor este)a dispon-vel. !ste servidor pode ser
um recurso ou um transportador. ! en$uanto o recurso estiver sendo utili,ado# as outras entidades $ue
c/egam ao mdulo &rocess t:m $ue esperar.
Fiura 02. Par*metros do %loco &R$CSS!
<ueue )a*el: Define o nome da <ueue )a*el associada com o mdulo.
Server Action: Define se um recurso 7sei7e< ou um transportador 7re'uest< 3 re$uerido pela
entidade.
ML
Resource "ame: \ vis-vel $uando o Server Action for Sei7e permite indicar o recurso a ser
solicitado. Pode?se optar por um recurso Knico# um con)unto de recursos# um mem%ro espec-fico de um
con)unto ou o recurso pode ser selecionado por uma e0presso.
Resource: 'ndica o nome do recurso a ser capturado.
Capacity Type: Define as caracter-sticas da capacidade de recurso.
Capacity: Define a capacidade do recurso.
Resource Statistics: !sta opo indica se as estat-sticas do recurso sero ou no coletadas.
&rocess Time: !ste campo define o tempo de processamento do recurso $uando este 3 ocupado
por uma entidade.
"e2t )a*el: Define o nome do pr0imo mdulo $ue a entidade se mover6. Se for feito um linA
para o pr0imo mdulo# o campo ser6 removido.
2o -cone <ueue podemos configurar as caracter-sticas da fila# como mostra a figura a seguir.
Fiura 03. Par*metros 'ueue do %loco &R$CSS!
Rankin, Rule: Define a caracter-stica da fila# podendo ser um F'FO# .. . 2o nosso caso a fila esta
NI
seguindo uma caracter-stica de prioridade# .o@ValorFrist.
2pression: Define $ual vari6vel se implica a regra adotada pelo Rankin, Rule!
-lo+o D)PA'T
O mdulo (epart 3 usado para coletar as estat-sticas do sistema e remover as entidades )6
processadas do modelo.
Fiura 0). Par*metros do %loco (&ART!
nter (ata
Station: !ste campo define o nome da estao $ue est6 associada a este mdulo.
Count
Counter: !ste campo define o nome do contador $ue ser6 incrementado ou decrementado.
Increment: !ste campo define o valor do incremento no contador.
Tally: !ste campo 3 vis-vel $uando o Tally name escol/ido 3 o Individual Tally# e define o nome
do Tally em $ue os dados estat-sticos so coletados.
N;
Attri*ute: !ste campo 3 vis-vel se a opo Interval 3 escol/ida em Type of Statistics e define o
nome usado para determinar as estat-sticas de intervalo.
-lo+o $)A()
O mdulo )eave 3 utili,ado para transferir uma entidade para uma estao ou um mdulo.
ma cone0o gr6fica pode ser utili,ada para transferir uma entidade para um outro mdulo e
uma entidade pode ser redirecionada para um mdulo atrav3s da refer:ncia )a*el no campo "e2t )evel.
Fiura 04. Par*metros do %loco )AV!
)a*el: !ste campo define o nome do la*el $ue ser6 associado a este mdulo.
N=
Irom Station: !ste campo especifica a estao de onde a entidade est6 sendo transferida.
To station: !ste campo indica o nome da estao em $ue as entidades se dirigiro.
Route time: !ste campo define o tempo $ue a entidade leva para se dirigir outra estao.
-lo+o (ariables
O mdulo Varia*les define as vari6veis glo%ais $ue sero utili,adas nos demais mdulos do
modelo de simulao.
Fiura 1'. Par*metros do %loco Varia*les!
Varia*les6 !ste campo define o nome das vari6veis glo%ais.
Add: 2ovas vari6veis sero adicionadas# neste mesmo campo se define os seus valores.
-lo+o Simulate
2o mdulo Simulate podemos inserir informa+es so%re o modelo de simulao. "omo o t-tulo#
data de $uando foi feito# e o nome do analista. (l3m disso neste mdulo so inseridas as informa+es
de replicao da simulao.
N>
Fiura 1(. Par*metros do %loco Simulate!
"um*er of Replications6 !ste campo define o nKmero inteiro da replicao da simulao a ser
e0ecutado.
)en,ht of Replication: !ste campo define o taman/o da replicao a ser simulada. "aso o
campo este)a em %ranco o seu valor ser6 infinito.
Warm4-p &eriod6 !ste campo define o tempo dese)ado para atingir o estado estacion6rio.
N8

PinottiFernandoLuiz M PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PinottiFernandoLuiz M PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTADUAL DE CAMPINAS

Você também pode gostar