2 qualidade de serviço na internet - dbd puc rio · qualidade de serviço na internet ... fontes...
TRANSCRIPT
2
Qualidade de Serviço na Internet
Qualidade de Serviço (QoS) é hoje um tópico de importância crescente,
considerado como fundamental para transformar a Internet em uma infra-
estrutura capaz de proporcionar vários tipos de serviços aos usuários. Assim
sendo, está em andamento um amplo esforço de desenvolvimento para dotar as
redes IP de uma estrutura capaz de dar tratamento diferenciado e garantias de
desempenho fim-a-fim a novas aplicações como VoIP, Vídeo-Conferência, entre
outras. Neste capítulo apresentamos os conceitos básicos de QoS em redes de
pacotes e mecanismos, algoritmos e protocolos desenvolvidos e utilizados para
implementação de uma rede com QoS.
Em redes de pacotes, um serviço pode ser caracterizado por alguns parâme-
tros significativos relacionados à transmissão de pacotes pela rede. Embora a
definição mais geral de Qualidade de Serviço seja baseada no conceito subjetivo
da satisfação do usuário, de forma prática e quantitativa, a Qualidade de
Serviço está associada a alguns parâmetros de desempenho. Os principais
parâmetros de QoS são:
• Vazão : É a taxa de transmissão ou transferência de dados efetiva entre
transmissor e receptor.
• Atraso : É o tempo necessário para um pacote percorrer a rede, do
transmissor ao receptor (atraso fim-a-fim).
• Variação do atraso (jitter): É a variação no atraso fim-a-fim.
• Probabilidade de Perda de Pacotes: A perda de pacotes ocorre devido
a saturação dos buffers ou por ultrapassagem do limite de atraso fim-
a-fim permitido. Um serviço com garantia probabilística permite que a
Características do Tráfego e Requisitos de QoS 20
probabilidade de perda seja diferente de zero, enquanto um serviço com
garantia determinística necessita que ela seja igual a zero. Em serviços
com garantia determinística, todos os pacotes encontrarão os requisitos
de desempenho requeridos, mesmo em situações de congestionamento da
rede. Serviços com garantia probabilística permitem uma provisão de re-
serva dos recursos da rede em situações de congestionamento, explorando
ao máximo a utilização da rede.
Diversos outros parâmetros de QoS podem ainda ser definidos como atraso
no estabelecimento de conexão, taxa de erro, disponibilidade da rede, entre
outros.
2.1
Características do Tráfego e Requisitos de QoS
Nesta seção apresentamos as características, padronizações e requisitos de
QoS para voz, vídeo e dados. Para cada aplicação apresentamos seus requi-
sitos em termos de atraso, variação do atraso, além de apresentar modelos
estatísticos para cada tipo de tráfego [6].
2.1.1
Voz
A característica básica de uma conexão de voz depende do sistema de digi-
talização e de transmissão empregado. Em geral transmitem-se pequenos pa-
cotes com tamanhos similares (algumas dezenas de bytes) em taxas que podem
variar de 5 Kbps até 64Kbps, dependendo do sistema de codificação e do ca-
beçalho adicionado. O ITU-T (Telecommunication Standardization Sector of
International Telecommunication Union ) padronizou várias codificações ao
longo dos anos [7]. A Tabela 2.1 enumera as principais, contendo informações
relevantes de cada uma delas.
Alguns valores típicos de parâmetros de QoS são geralmente adotados para
o serviço de voz, como se comenta a seguir [6]. A interatividade impõe um
atraso máximo fim-a-fim na faixa de 100 a 150 ms. Isto inclui, além do atraso
Características do Tráfego e Requisitos de QoS 21
Padrão Codificação Taxa
G.711 PCM 64 Kbps
G.721 Adaptive Differential 32 Kbps
G.728 CELP 16 Kbps
G.729 CS- ACELP 8 Kbps
G.729 A A CS-ACELP 4 Kbps
Tabela 2.1 Padronização de Voz
ocorrido na codificação de voz, os atrasos devidos a empacotamento, tempo de
transmissão na rede, ajuste da variação estatística do atraso e decodificação. A
variação estatística do atraso não deve exceder 50 ms para assegurar uma suave
compreensão no receptor. Quanto às perdas, sabe-se que é possível conviver
com taxas relativamente elevadas de perdas eventuais. Porém, sabendo-se que
a perda de pacotes na Internet acontece em surtos, isto pode resultar em longos
períodos sem informação. Estes períodos devem ser limitados a 60 ms para
não afetar a inteligibilidade do receptor.
2.1.1.1
Modelos Estatísticos para Voz
Pode-se observar dois períodos característicos em uma fonte de voz: o
período ativo, que é o período de fala, e o inativo, que é o período de silêncio.
No período ativo, a fonte gera pacotes de tamanho fixo em intervalos regulares,
enquanto que no inativo nenhum pacote é gerado. Uma boa aproximação para
uma conversa normal é aquela que considera o tempo de duração de um período
dado por uma distribuição exponencial, embora apresente imprecisões quanto
ao período inativo, visto que este pode representar um silêncio prolongado
durante a fala de outra pessoa ou um silêncio curto devido a pausas durante
a fala. Aproximar o processo de chegada por uma distribuição exponencial,
que é um processo sem memória, significa considerar o processo como sendo
um processo de renovação, ou seja, sem correlação entre chegadas sucessivas.
Entretanto, ao se considerar o tráfego produzido pelo conjunto de fontes de
Características do Tráfego e Requisitos de QoS 22
voz, tem-se que o processo resultante não é mais um processo de renovação
visto que a taxa instantânea de chegada varia de acordo com a quantidade de
fontes ativas no momento. Podemos citar como modelos estatísticos para voz:
Fontes ON/OFF e Fontes Fluxo de Fluido [1].
2.1.2
Vídeo
Da mesma forma que a voz, as características do tráfego de vídeo dependem
do padrão utilizado para codificação e compressão. As taxas de bits podem
ter valores diversos a partir de dezenas Kbps até a ordem de dezenas de Mbps.
Esta taxa pode ser aproximadamente constante (tráfego CBR) ou variar ao
longo do tempo (tráfego VBR). Atualmente os principais padrões são H.261,
H.263, MPEG-1, MPEG-2 [7] cujas principais características são resumidas na
Tabela 2.2 .
Padrão Codificação Taxa
H.261
DCT, similar ao JPEG, e
um algoritmo DPCM (Diffe-
rential Pulse Code Modula-
tion) com estimativa de mo-
vimento
p*64Kbps (p=1,2,3,4...30)
H.263 O mesmo do H.261 15 à 20 Kbps
MPEG-1VHS: 360x280 píxeis com 30
quadros por seg1.5 Mbps
MPEG-2CCIR 601: 720x480 píxeis
com 30 quadros por seg2 à 10 Mbps
Tabela 2.2 Padronização de vídeo
Os requisitos de atraso para vídeo dependem da natureza da aplicação.
Como a voz, a comunicação de vídeo interativo requer um baixo atraso fim-a-
fim (100-150 ms) [6]. Já no caso de transmissão em broadcast unidirecional ou
vídeo sob demanda a tolerância é bem maior. Quanto às perdas, observa-se que
Características do Tráfego e Requisitos de QoS 23
uma taxa de 3% pode afetar mais de 30% dos quadros, devido às dependências
do codificador. Conseqüentemente, a probabilidade de perda de pacotes deve
ser mantida em níveis baixos.
2.1.2.1
Modelos Estatísticos para Vídeo
Sinais de vídeo geralmente consomem grande banda passante. Por exemplo,
para uma fonte transmitindo quadros de 512 x 512 a cada 1/30 s, obter-se-á
uma taxa aproximada de 63 Mbps, em codificação PCM. O que ocorre, en-
tretanto, é que, a uma taxa de transmissão de quadros tão alta, a maioria
destes contém apenas pequenas variações sobre os quadros anteriores, possibi-
litando assim uma codificação que observe a correlação entre os quadros. As
fontes de variação, de um modo geral, podem ser classificadas em mudanças
de cenas, que é uma variação descontínua, movimentos dentro de uma cena,
que são variações suaves com correlação temporal ou grande variações ocasio-
nais devido a movimentação de pessoas e da câmera, e mudanças na sutileza
dos detalhes das imagens bidimensionais do vídeo. As variações de longo-
intervalo surgem principalmente das mudanças de contexto no vídeo devido a
mudanças de cena. A mudança na taxa binária ocorre como um degrau e as
características da variação das taxas binárias seguintes à mudança de cena são
completamente diferentes daquelas antes da mudança. A escala de tempo des-
tas mudanças é da ordem de vários segundos. As variações de curto-intervalo
são causadas basicamente pela mudança de contexto da imagem dentro de uma
única cena. Estas variações de taxas binárias mudam suavemente e são corre-
lacionadas temporalmente. Estas correlações decaem exponencialmente com o
tempo. Os mais importantes modelos estatísticos para vídeo são os seguintes:
os Processos Auto-Regressivos, as Cadeias de Markov de Tempo Contínuo e
os Processos de Poisson Modulados por Markov [1]. Os dois primeiros são
modelos para variações de curto-intervalo, onde apenas são consideradas as
variações das taxas binárias dentro de uma cena. Conclui-se, portanto, que
esses modelos são úteis para fontes de vídeo que apresentam uma distribuição
das taxas binárias sem súbitas variações e alta correlação intra-quadro. Os
Características do Tráfego e Requisitos de QoS 24
dois últimos são modelos para variações de longo-intervalo.
2.1.3
Tráfego de Dados na Internet
As principais formas de tráfego na Internet resultam de aplicativos como
Telnet (acesso remoto) e WEB (FTP e seções HTTP).
2.1.3.1
Telnet
A aplicação Telnet é utilizada para acesso a um terminal remoto. Portanto,
as mensagens típicas, correspondentes a comandos e respostas trocadas entre os
terminais, são pequenos datagramas (em torno de 50 bytes). Ocasionalmente,
os resultados dos comandos digitados pelo usuário são enviados de volta pelo
servidor. Tem-se então um tráfego assimétrico, cerca de vinte vezes maior no
sentido do servidor para o usuário. A aplicação Telnet é altamente interativa e,
portanto, deve atender a limitação de atraso. O atraso começa a ser percebido
a partir de 100 ms e atrasos maiores que 200 ms tornam a interatividade
sofrível [6]. Por outro lado, a perda de pacotes também acaba resultando em
atraso geralmente inaceitável pois o tempo de retransmissão possui em geral
um valor relativamente elevado. Conseqüentemente, o tráfego Telnet necessita
limitar adequadamente os níveis de atraso e perda de pacotes. Todavia, o
tempo entre pacotes é limitado pela velocidade de digitação do usuário, o qual
raramente é maior que 5 caracteres por segundo, dando um mínimo de 200
msec para o intervalo de chegada de pacotes. Conseqüentemente, o tráfego
gerado pelo Telnet utiliza pouca banda e possui baixa explosividade.
2.1.3.2
WEB
Estudos sobre o tráfego WEB mostram as seguintes características básicas:
(i) a maioria das requisições são menores que 500 bytes; (ii) as respostas são
tipicamente menores que 50 Kbytes; estes valores, porém, podem ser bem
A Internet Atual 25
maiores quando se trata de download de grandes arquivos da rede.
Tipicamente, o tempo máximo aceitável de espera por uma página está em
torno de 5 segundos [6]. Adicionalmente, a previsibilidade é um outro fator
importante no tempo de resposta da rede. Ou seja, o tempo necessário para
baixar um arquivo não deve variar muito para que ele seja previsível. Nesse
contexto, é importante distinguir seções HTTP interativas, onde páginas da
rede são carregadas (arquivos html e imagens), de FTPs não interativos, que
emprega o HTTP para baixar grandes arquivos. Em [6] são apresentados re-
sultados de modelagem do tráfego na Internet. Mostra-se que o intervalo de
chegada de pacotes obedece a uma distribuição Pareto de calda pesada, resul-
tando em um tráfego explosivo. As respostas HTTP obedecem a uma distri-
buição de calda pesada, e o tráfego gerado pela agregação de várias conexões
WWW exibe-se como auto-similar.
2.2
A Internet Atual
2.2.1
O Serviço de Melhor-Esforço
O protocolo IP oferece um serviço sem conexão baseado em datagramas,
que não garante a entrega dos datagramas a tempo, não garante que eles che-
guem ao destino na ordem correta e nem mesmo garante que eles cheguem
ao destino. Ou seja, a rede tenta encaminhar todos os pacotes o mais rápido
possível, mas não pode fazer qualquer tipo de garantia quantitativa sobre a
Qualidade de Serviço. Assim, o serviço oferecido pelas redes IP é caracteri-
zado pela ausência de garantias em relação à QoS efetivamente oferecida pelas
mesmas, sendo chamado serviço de melhor-esforço.
O provedor de serviços compromete-se a realizar o maior esforço possível
com intuito de fornecer um serviço da mais alta qualidade. Contudo, isso
nem sempre acontece, pois o tráfego de dados é por natureza imprevisível e
em rajadas, e não é economicamente viável prover a rede para satisfazer as
demandas de pico. Assim, em situações de pico de tráfego, surge eventual-
A Internet Atual 26
mente o problema de congestionamento devido ao esgotamento dos recursos
disponíveis. Neste caso, os roteadores podem retardar ou até mesmo descartar
pacotes resultando em uma sensível degradação da qualidade percebida pelos
usuários.
O serviço de melhor-esforço, oferecido pelo protocolo IP, tem como grande
vantagem a sua simplicidade, podendo servir de base para que serviços mais
completos possam ser desenvolvidos. É o caso do protocolo TCP, que fornece
serviço fim-a-fim, orientado à conexão e bidirecional, apresentando facilidades
de controle de erros e prevenção de congestionamento. Este serviço é indi-
cado às aplicações que exijam um alto grau de confiabilidade da rede, como a
transferência de arquivos (FTP) por exemplo.
2.2.2
Controle de Congestionamento
O congestionamento em redes de pacotes é basicamente um problema de
compartilhamento de recursos. Ele ocorre quando os usuários inserem na rede
uma quantidade maior de pacotes do que ela é capaz de tratar. Na Internet, a
ocorrência de congestionamento é devida, por um lado, à natureza imprevisível,
e em rajadas, do tráfego de dados. Por outro lado, o serviço de melhor-esforço
não supõe nenhum tipo de controle de admissão nem reserva de recursos para
limitar a influência desses fatores.
Existem duas atividades distintas relacionadas ao controle de congestiona-
mento. A primeira é a prevenção de congestionamento que tenta detectar
possíveis condições que levem a congestionamentos futuros e executar proce-
dimentos para impedi-los. A segunda é a correção de congestionamento, que
atua na rede quando um congestionamento já ocorreu para que ela volte ao
seu estado normal.
Na Internet, o controle de congestionamento é realizado fim-a-fim, na ca-
mada de transporte, mas somente pelo protocolo TCP. A taxa de transmissão
de dados do protocolo TCP é controlada pelas condições da rede e por isso os
fluxos TCP são chamados de “compreensivos” ou “responsáveis”, porque res-
pondem positivamente as notificações de congestionamentos. O UDP (User
A Internet Atual 27
Datagram Protocol), por outro lado, não realiza nenhum tipo de controle de
congestionamento. Em face a congestionamentos, os fluxos UDP não diminuem
a taxa de transmissão de dados, a não ser que as aplicações o façam. Por isso,
são chamados de “agressivos” ou “não compreensivos”. Como cerca de 90% dos
pacotes na Internet pertencem a fluxos TCP, em geral os congestionamentos
são resolvidos de maneira adequada.
Os algoritmos de controle de congestionamento do protocolo TCP (que fo-
ram criados por Van Jacobson) foram padronizados pela RFC 1122 e são apre-
sentados com mais detalhes na RFC 2581. São quatro os algoritmos utilizados
pelo TCP: slow start, congestion avoidance, fast retransmit e fast recovery. O
objetivo global deles é levar a rede a um estado estável de plena utilização, per-
mitindo a introdução de um novo pacote à medida que outro pacote é retirado.
Desse modo, os recursos na rede não são desperdiçados, ao mesmo tempo que
os congestionamentos são evitados. Cada transmissor TCP fica o tempo todo
monitorando a rede, tentando transmitir o máximo de segmentos possível mas
diminui sua taxa ao detetar perda de pacote.
2.2.3
Algoritmos de Controle de Congestionamento do Protocolo TCP
A fim de evitar tráfego desnecessário na rede, o TCP realiza controle de
congestionamento através de basicamente quatro algoritmos: slow start, con-
gestion avoidance, fast retransmit e fast recovery [8].
2.2.3.1
Slow Start
Uma máquina não tem nenhum conhecimento do estado da rede quando
transmite informação numa conexão TCP. Os algoritmos slow start e conges-
tion avoidance tentam conduzir a transferência, com a finalidade de evitar
o uso inapropriado dos recursos da rede, para que de forma gradual seja al-
cançado um ponto de equilíbrio entre as duas máquinas. O slow Start é um
mecanismo que controla o comportamento transitório da conexão levando-a
ao ponto de equilíbrio de forma rápida, que entretanto não cause congestiona-
A Internet Atual 28
mento na rede. Esse algoritmo inicia a conexão com uma janela de transmissão
pequena, aumentando-a de forma exponencial até que se atinja a capacidade
da rede. Isto se aplica tanto a uma conexão que se inicia como ao reinicio após
um estouro do temporizador, quando o congestionamento já existe e se deseja
esvaziar o meio e começar novamente a manipulação da janela de transmissão.
O algoritmo pode ser resumido nos seguintes passos, onde representa-se por
CWND (Congestion Window) o tamanho da janela do TCP:
1 No início da conexão, CWND recebe o valor de 1 segmento1;
2 A cada novo ACK (não duplicado)2 recebido pelo transmissor, CWND é
incrementada de um segmento;
3 A janela de transmissão é a menor entre CWND e a janela de recepção.
O processo de aumentar a CWND de um pacote a cada ACK recebido gera
um crescimento exponencial da variável, pois, para cada RTT3 bem sucedida
(onde todos os pacotes enviados numa janela de transmissão são recebidos
pelo destino) a CWND dobra de tamanho. É claro que em um dado momento
se atinge a capacidade da rede, pois rajadas cada vez maiores exigem espaço
nas filas dos roteadores. Do ponto de vista do slow start, a única ação a ser
tomada com relação a isto é que quando ocorrer um time-out, CWND volta
a 1 segmento e o algoritmo é reiniciado. Outros algoritmos que veremos mais
adiante tratam da adaptação do transmissor nas limitações de banda-passante
na rede. O objetivo do slow start é permitir que uma conexão iniciada ou
reiniciada após um time-out atinja rapidamente o seu ponto de equilíbrio.
1Segmento é o nome dado à Unidade de Dados do Protocolo ou PDU (Protocol Data
Unit) da camada de transporte.2O protocolo TCP pode repetir um mesmo ACK relativo a um determinado segmento
não recebido a medida que recebe segmentos de ordem superior.3RTT- Tempo de ida e volta (Round Trip Time). É o tempo estimado pelo algoritmo
para um pacote ir da origem ao destino e voltar. Uma boa estimativa deste valor é objeto
de pesquisa.
A Internet Atual 29
2.2.3.2
Congestion Avoidance
Como o Slow Start incrementa a janela de transmissão exponencialmente,
é inevitável que, num determinado ponto, a capacidade da rede seja ultrapas-
sada, provocando perda de pacotes. Neste momento é implementado o Con-
gestion Avoidance. Este algoritmo procura incrementar o CWND de forma
mais conservadora, como indicado abaixo:
1 Quando ocorrer um estouro de temporização (time-out), CWND passa a
CWND/2;
2 Para cada novo ACK recebido (não duplicado), incrementa-se CWND de
1/CWND;
3 A janela de transmissão é a menor entre a janela do receptor e CWND.
2.2.3.3
Slow Start e Congestion Avoidance
Na prática, o slow start e o congestion avoidance são implementados em
conjunto. A fusão dos dois algoritmos é bastante simples. Além de CWND, que
os dois usam, adiciona-se a variável SSTHRESH (slow start threshold, o limite
do slow start), que determina qual do dois estará ativo. A implementação em
conjunto fica:
1 Quando ocorrer um time-out, SSTHRESH = CWND/2;
2 Se CWND < SSTHRESH, a janela é manipulada pelo slow start ;
3 Se CWND > SSTHRESH, a janela é manipulada pelo congestion avoidance.
Assim, o slow start abre a janela exponencialmente até que haja um time-
out. Nesse ponto o SSTHRESH recebe o valor de CWND/2. Depois desta
fase inicial, se o limiar for atingido o congestion avoidance assume o controle,
aumentando a janela lentamente de modo a conseguir mais banda passante
disponível na rede. Se for detectado uma perda na rede, o SSTHRESH cai
para metade do seu valor no momento da perda.
A Internet Atual 30
2.2.3.4
Fast Retransmit
O mecanismo fast retransmit visa apressar a retransmissão de segmentos
quando a rede se encontra em uma situação de congestionamento moderado.
Como a rede IP é não orientada a conexão, a cada pacote calcula-se a melhor
rota. Assim, é possível que alguns pacotes cheguem fora da ordem em que fo-
ram enviados. Logo, o TCP não sabe se o ACK duplicado foi causado por um
pacote perdido ou por uma simples reordenação. Assume-se que, no caso de
pacotes enviados fora de ordem, serão recebidos no máximo dois ACKs dupli-
cados até que o segmento fora de ordem seja processado e um novo ACK seja
gerado. Então, se chegarem três ACK duplicados, isto é interpretado pelo TCP
como um indicativo de perda de pacote e o segmento é retransmitido. Assim,
evita-se que se tenha que esperar o estouro do temporizador e a retransmissão
é feita mais rapidamente.
2.2.3.5
Fast Recovery
O fast recovery é implementado em conjunto com o fast retransmit, para o
caso de necessidade de retransmissão por recebimento de ACK duplicado.
1 Ao receber três ACKs duplicados consecutivos, SSTHRESH = CWND/2.
2 Retransmite-se o segmento supostamente perdido;
3 CWND = SSTHRESH + 3 segmentos;
4 A cada novo ACK duplicado, incrementa-se CWND de 1 segmento; se for
possível, transmite-se um novo segmento;
5 Ao chegar um novo ACK, CWND = SSTHRESH.
Deve-se notar que o primeiro e o último passo do algoritmo acima corres-
pondem ao congestion avoidance, ou seja, a janela é reduzida à metade. No
entanto, para evitar o slow start, o fast recovery “infla” a janela de congestio-
namento, incrementando-a de um segmento para cada ACK duplicado recebido
A Internet Atual 31
(passos 3 e 4). Deste modo, para cada pacote que deixa a rede, um novo é
inserido. No passo 3, CWND é incrementada de 3 segmentos de uma vez
por causa dos três ACKs duplicados que são necessários para disparar o fast
recovery, indicando que três pacotes já deixaram a rede. O fast retransmit está
implementado no passo 2.
2.2.4
Implementações do Protocolo TCP
Com a evolução dos algoritmos de controle de congestionamento descritos
anteriormente, diferentes versões do protocolo TCP foram sendo implemen-
tadas. De acordo com os novos mecanismos propostos, o software do TCP
veio sofrendo modificações de modo a incorporar as modificações sugeridas.
Nesta seção serão brevemente descritas as versões mais conhecidas do proto-
colo, ilustrando sua evolução no que diz respeito aos algoritmos de controle de
congestionamento.
2.2.4.1
Tahoe
As primeiras implementações do TCP não incluíam qualquer mecanismo de
controle de congestionamento. Elas simplesmente usavam a janela do receptor
para transmissão e um temporizador de retransmissão. Esta retransmissão
era feita de acordo com a estratégia “go-back-n”, ou seja, todos os segmentos
após o segmento dado por perdido eram retransmitidos. Não havia nenhum
tipo de busca de realimentação de informações que indicassem a situações da
rede. Além disso, os temporizadores do TCP eram deficientes no cálculo da
estimativa do RTT, o que provocava problemas nas retransmissões. O Tahoe
foi a primeira implementação do TCP a incluir o controle de congestionamento.
O Tahoe usa o slow start, o congestion avoidance e o fast retransmit, além de
modificações no estimador de RTT.
A Internet Atual 32
2.2.4.2
Reno
O TCP Reno foi o sucessor do Tahoe, incorporando uma modificação ao
fast retransmit : o fast recovery. O TCP Reno é a versão do protocolo que
encontra-se mais difundida na Internet atualmente.
2.2.4.3
NewReno
O fast recovery é uma boa solução para uma única perda numa mesma
janela de transmissão. Caso ocorram múltiplas perdas, o algoritmo irá dividir
pela metade a janela de congestionamento a cada perda. Por usar este algo-
ritmo, o TCP Reno tem seu desempenho deteriorado em presença de múltiplas
perdas numa mesma janela.
Para solucionar este problema, foi criado o TCP New Reno. O algoritmo
do New Reno utiliza o conceito de reconhecimento parcial. Note que quando
o TCP percebe que ocorreu uma perda de pacote pela indicação de ACKs
duplicados, a próxima informação nova para o emissor só será dada na che-
gada do reconhecimento daquele pacote retransmitido. Com uma única perda
esse reconhecimento irá confirmar o pacote retransmitido e todos os seguintes
que chegaram sem problemas antes do início do fast retransmit. No caso de
múltiplas perdas, o reconhecimento irá confirmar todos os pacotes recebidos
até a próxima perda. Este reconhecimento que não confirma todos os paco-
tes enviados antes do início do fast retransmit é chamado de reconhecimento
parcial.
Logo o TCP New Reno, como utiliza reconhecimentos parciais, mantém-se
no fast retransmit, evitando múltiplas quebras da janela de congestionamento,
mesmo na presença de várias perdas. Para a implementação do reconhecimento
parcial, o New Reno utiliza a variável recover, nela fica armazenado o valor de
seqüência mais altos já transmitido. O algoritmo é descrito a seguir:
1 O recebimento do terceiro ACK duplicado faz com que SSTHRESH =
CWND/2. Grava-se o maior número de seqüência na variável recover ;
A Internet Atual 33
2 Retransmite-se o segmento perdido. CWND = SSTHRESH + 3 segmentos
- inflando articialmente a janela de congestionamento pelo número de
pacotes que deixaram a rede (três);
3 A cada novo ACK duplicado, incrementa-se CWND de 1 pacote; se for
possível, transmite-se um novo segmento;
4 Ao chegar um novo ACK:
a) Se o ACK inclui o dado cujo número de seqüência ficou guardado em
recover, fazer CWND = SSTHRESH. Sair do fast recovery ;
b) Se o ACK não reconhece todos os dados, ele é um ACK parcial. Re-
transmitir o primeiro segmento não reconhecido, desinflar a janela
de transmissão pelo número de reconhecimentos recebidos. Somar
1 pacote à janela de congestionamento e enviar novos segmentos, se
o tamanho de CWND permitir. Não sair do fast recovery (ou seja,
se algum novo ACK duplicado chegar, repetir a partir do passo 3
acima).
A contribuição do New Reno é fazer com que múltiplos pacotes, de uma
mesma janela de transmissão, sejam retransmitidos sem esgotar o tempori-
zador. A uma taxa de um pacote por RTT, até que todos os dados perdidos
sejam retransmitidos. Outra contribuição desta versão é o parâmetro chamado
maxburst. Ele limita o número máximo de pacotes que pode ser enviados numa
rajada de dados após o reconhecimento, mesmo que a janela permita. O max-
burst só é necessário no momento do envio de pacotes da primeira janela de
dados após o término de execução do algoritmo fast retransmit.
2.2.4.4
Vegas
Uma implementação proposta para o TCP que apresenta algumas modifi-
cações mais profundas nos mecanismos tradicionais deste protocolo é o TCP
Vegas. As alterações do Vegas resumem-se ao lado do transmissor, ou seja,
sua política de emissão de reconhecimentos é a mesma do TCP Reno. Isto
A Internet Atual 34
facilitaria sua adoção por parte da comunidade da Internet, já que os seus
benefícios podem ser desfrutados mesmo que na outra ponta haja uma versão
mais antiga (ao contrário, por exemplo, do SACK ).O Vegas possui um algo-
ritmo de início de conexão, um para o estado estacionário e um para controlar
as retransmissões. Entretanto, os três algoritmos são bastante diferentes dos
vistos no TCP Reno.
O mecanismo de congestion avoidance do Vegas é baseado no cálculo da
estimativa da vazão da conexão. A partir desta estimativa, são arbitrados um
limite mínimo e um máximo de vazão por parte da conexão TCP. O Vegas
busca manter a vazão dentro destes limites através da manipulação da janela
de congestionamento (CWND).
A modificação feita ao mecanismo de slow start tem como meta evitar que
o aumento exponencial no início da conexão gere congestionamento na rede,
como pode ocorrer com o TCP Reno, por exemplo. Deste modo, no início
de uma conexão do TCP Vegas ocorre um aumento exponencial, mas a cada
dois RTTs. Isto é feito aumentando a janela de um segmento para cada ACK
recebido (como nos outros TCPs) em um RTT, e a mantendo fixa durante
o outro RTT. Durante o ciclo em que a janela fica inalterada, é realizada a
comparação entre a vazão esperada e a real, descrita anteriormente. Quando a
vazão real fica abaixo da esperada pelo equivalente a um buffer (um segmento),
o Vegas muda para o modo linear increase/decrease.
A estimação do RTT é feita da seguinte maneira: a cada segmento enviado e
a cada ACK recebido, o Vegas lê o relógio do sistema e registra o tempo lido. O
cálculo do RTT é feito usando os mesmos algoritmos do Reno, mas as medidas
de tempo usadas possuem maior exatidão. Isto deve permitir que o TCP
trabalhe com uma estimativa de RTT mais exata, o que possibilita as alterações
propostas para os algoritmos de retransmissão. O Vegas mantém o mecanismo
de time-out do Reno como um último recurso caso os seus mecanismos não
percebam a perda de um segmento. No entanto, o objetivo é justamente reduzir
ao máximo o número de time-outs tradicionais, já que estes normalmente são
um mecanismo ineficiente para a determinação das retransmissões.
A Internet Atual 35
2.2.4.5
Sack
O TCP com reconhecimento seletivo não incorpora qualquer mudança nos
algoritmos de controle de congestionamento. Neste aspecto, ele é idêntico ao
Reno, apenas apresentando a diferença na política de retransmissões decorrente
da opção de reconhecimentos seletivos.
A Tabela 2.3 apresenta de forma condensada as diferentes implementações
do TCP explicadas aqui, para que se possa observar as diferenças entre elas,
com relação aos mecanismos de controle de congestionamento e à política de
reconhecimentos empregada.
TCP Slow Congestion Fast Fast Política de
Start Avoidance Retransmit Recovery Reconhecimentos
Tahoe sim sim sim não cumulativo
Reno sim sim sim sim cumulativo
NewReno sim sim sim sim
cumulativo,
diferencia ACKS
parciais
Vegas
Próprio,
mais
suave
Próprio,
linear
increase /
decrease
Não se
aplica
Não se
aplicacumulativo
Sack sim sim sim simCumulativo, com
seletividade
Tabela 2.3 Comparação das diferentes implementações do TCP
As diversas implementações do TCP implicam em diferentes comportamen-
tos nas situações de congestionamento de rede, levando a variações no desem-
penho do protocolo. Cada implementação possui vantagens e desvantagens sob
determinados cenários de congestionamento.
Mecanismos para implementação de QoS 36
2.3
Mecanismos para implementação de QoS
Uma rede com QoS é uma rede capaz de garantir valores mínimos para
parâmetros de QoS necessários a uma determinada aplicação. Do ponto de
vista operacional, isto requer o estabelecimento de Contratos de Serviço (Ser-
vice Level Agreements - SLA) onde é especificada a característica do tráfego e
os requisitos de QoS, isto é, os valores dos parâmetros de QoS que a rede se
compromete a atender. Tipicamente, são estabelecidas classes de serviço [31],
cada uma delas com diferentes formas de garantia de QoS.
Para atender a este paradigma, é necessário dotar a rede de diversos meca-
nismos de controle de tráfego a serem incorporados basicamente nos roteado-
res: condicionamento, policiamento e modelagem de tráfego; políticas de filas
(disciplinas de serviço); gerenciamento ativo de filas (controle de congestiona-
mento); controle de admissão; reserva de recursos e entre outros.
A seguir apresenta-se um resumo dos principais mecanismos básicos de
controle de tráfego mencionados:
2.3.1
Escalonamento - Disciplinas de Serviço
O escalonamento ou agendamento é a função que ordena o encaminhamento
(serviço) de pacotes que estão nos buffers dos roteadores. Em uma rede sem
classes de serviço, todos os pacotes que chegam ao buffer têm o mesmo tra-
tamento. Neste caso, o problema corresponde a uma fila FCFS (First Come
First Served). A existência de diferentes classes de serviço exige o estabe-
lecimento de critérios de tratamento diferenciado para estas classes, ou seja,
disciplinas de serviço que permitam garantir a cada classe os parâmetros de
QoS contratados. O escalonamento pode ser classificado como conservativo
(work-conserving) e não conservativo (nonwork-conserving) [35]. Quanto à re-
lação entre escalonamento conservativo e escalonamento não conservativo, no
primeiro, o escalonador só está inativo quando não tem dados para enviar e
no segundo, o escalonador pode estar inativo mesmo quando tem dados para
Mecanismos para implementação de QoS 37
enviar. Com isto ocorre um desperdício de largura de banda que é uma des-
vantagem. Porém ganha-se previsibilidade de tráfego e desta forma pode-se
reduzir o tamanho do buffer e diminuir a variação do atraso (jitter). Ou seja, o
escalonamento não conservativo apesar de desperdiçar largura de banda, torna
a manutenção da rede mais simples.
Nesta seção apresentaremos as disciplinas de serviço conservativas mais
usuais: Virtual Clock (VC), RR (Round Robin), WRR (Weight Round Ro-
bin), PQ (Priority Queueing), FQ (Fair Queueing) e WFQ (Weighted Fair
Queueing). As duas últimas também são chamadas de Packetized Generalized
Processor Sharing (PGPS).
2.3.1.1
VC (Virtual Clock )
O Virtual Clock é um algoritmo de controle de tráfego baseado no TDM
(Time Division Multiplexing) que objetiva controlar a taxa de transmissão do
fluxo de dados, monitorar o fluxo de dados estatísticos, provendo garantias
quanto à vazão e proteção entre os fluxos, e resultando em baixos atrasos nas
filas (porém sem garantias quanto ao atraso fim-a-fim). Um sistema TDM eli-
mina completamente a interferência entre os fluxos já que cada fluxo transmite
apenas em intervalos de tempo específicos. Entretanto, a capacidade do canal
é desperdiçada quando em um dado intervalo de tempo, o fluxo correspondente
não possui dados prontos para serem transmitidos.
2.3.1.2
RR (Round Robin)
O maior problema do escalonamento FCFS é a possibilidade de uma fonte
mal comportada (gerando pacotes a uma taxa significativamente alta) preju-
dicar o escalonamento de outros fluxos, o que é normalmente chamado de falta
de proteção de fluxo. O Round Robin (RR) fornece proteção de fluxo através
da alocação de uma fila distinta para cada classe de tráfego e de rodízio de
serviço entre as filas ativas, como ilustrado na Figura 2.1.
Em princípio o mecanismo Round Robin dedica o mesmo tempo (mesma
Mecanismos para implementação de QoS 38
banda) para cada fila. Neste caso, o serviço de um pacote completo antes de
mudar de fila faz com que pacotes maiores obtenham um percentual maior
do uso da banda. Uma alternativa é uma leitura bit-a-bit, de tal forma que
somente após a leitura completa de um pacote ser concluída o mesmo é enca-
minhado. No RR, uma fonte mal comportada somente vai atrasar o encami-
nhamento dos seus pacotes.
O RR distribui a banda disponível de forma igualitária entre as fontes
transmissoras, não permitindo a utilização de esquemas de prioridade ou dife-
renciação de serviços. Portanto, todas as classes são sempre atendidas com a
mesma QoS. Finalmente, o RR permite o fornecimento de serviços garantidos,
uma vez que o fluxo de uma classe não interfere no das outras, como ocorre
na FCFS. No exemplo da Figura 2.1, uma banda igual a m é compartilhada
igualmente por duas fontes, cada qual sendo atendida a uma taxa m2.
Cla ssificador r
r
m
b
Figura 2.1 Modelo RR
2.3.1.3
WRR (Weighted Round Robin)
O WRR é uma generalização do RR pela implementação da possibilidade
de uso de um tempo desigual na leitura das filas, permitindo uma distribuição
da banda disponível de forma diferenciada, de acordo com a QoS solicitada por
cada classe de serviço. Na Figura 2.2, os pesos w1, w2 e w3 regulam a leitura
das filas. A largura de banda disponível m é compartilhada pelas fontes de
acordo com os referidos pesos". É feita análise cíclica de filas através do envio
de um pacote por fila.
Mecanismos para implementação de QoS 39
Classificador r a
m
b a
r b
r d
w 1
w 3
w 2
Figura 2.2 Modelo WRR
2.3.1.4
PQ (Priority Queueing)
No escalonamento com prioridade PQ , o tráfego de entrada é classificado
em diferentes níveis de prioridade. Os pacotes que não são marcados levam
configuração padrão, isto é, são tratados de acordo com nível de prioridade
padrão previamente definido. Neste mecanismo, o tráfego classificado e mar-
cado como prioritário tem preferência absoluta em relação aos outros fluxos,
ou seja, uma fila de menor prioridade só será servida se a fila prioritária estiver
vazia. Embora vantajosa para o tráfego de maior prioridade, esta estratégia
pode causar um aumento de jitter e atrasos consideráveis em aplicações de me-
nor prioridade. Numa situação extrema pode acontecer até de um fluxo com
menor prioridade nunca chegar a ser enviado se o fluxo de maior prioridade
ocupar toda largura de banda. Isso ocorre em conexões de baixa velocidade.
2.3.1.5
FQ (Fair Queueing)
A idéia básica do Fair Queueing é bastante simples. Se N canais compar-
tilham um único canal de saída, então cada canal tem direito a 1/N da banda
passante. No entanto, se algum canal utilizar menos, o restante é distribuído
igualmente entre os demais. Isto é obtido através de um mecanismo de trans-
missão do tipo RR (Round Robin) entre os canais. Apesar de não considerar
nenhum parâmetro de QoS, o FQ oferece proteção entre os fluxos em relação
à banda passante utilizada e maximiza o intercalamento entre os pacotes dos
diferentes fluxos. No entanto, considera que todos os fluxos possuem as mes-
mas necessidades, fornecendo a cada um a mesma parcela da banda passante
do canal.
Mecanismos para implementação de QoS 40
2.3.1.6
WFQ (Weighted Fair Queueing)
WFQ é uma aproximação do Fluid Fair Queueing (FFQ) ou Generalized
Processor Sharing (GPS). O princípio do escalonador se baseia em visitar cada
fila que não esteja vazia por vez, servindo uma quantidade infinitesimal de
cada fila. Do ponto de vista lógico cada pacote está numa fila diferente e o
escalonador usa um mecanismo de RR, ignorando as filas vazias. Contudo o
GPS não pode ser implementado uma vez que podemos servir apenas pacotes.
Com isso precisamos emular GPS através de técnicas de WFQ.
O WFQ é uma generalização do FQ pela implementação da da possibilidade
de uso de um tempo desigual na leitura das filas, permitindo uma distribuição
da banda disponível de forma diferenciada, de acordo com a QoS solicitada
por cada classe de serviço, sendo que o WFQ serve mais de um bit por visita.
FQ e WFQ são mais justos uma vez que eles dão preferência aos fluxos
menos ativos. WFQ é superior a WRR no caso de pacotes de tamanho variável
ou quando o tamanho médio dos pacotes é desconhecido à priori.
2.3.2
Gerenciamento Ativo de Filas
Um dos principais obstáculos ao atendimento de requisitos de QoS é a
ocorrência de congestionamento. Sabe-se que o congestionamento provoca o
transbordamento de buffers com conseqüente perda de pacotes. Aumentando-
se o tamanho do buffer diminui-se a perda de pacotes, mas se tende a aumentar
o atraso. Observa-se, portanto, que a dimensão e o gerenciamento dos pacotes
no buffer são fatores importantes em uma rede com QoS.
O descarte de pacotes por transbordamento pode ser considerado um geren-
ciamento estático ou passivo. Em contrapartida, foram propostos recentemente
mecanismos de gerenciamento ativos de fila, ou seja mecanismos dinâmicos cuja
ação específica depende do estado do buffer. Estes mecanismos são descritos a
seguir.
Mecanismos para implementação de QoS 41
2.3.2.1
RED (Random Early Detection)
O mecanismo RED foi originalmente proposto em 1993 por Floyd e Jacob-
son [32]. O RED permite ao roteador descartar pacotes antes de um satura-
mento da fila. Conseqüentemente, uma resposta ao congestionamento ocorrerá
mais cedo resultando num menor tamanho médio da fila.
A utilização do RED é interessante por algumas razões: primeiro, o atraso
na fila irá diminuir, tornando-se interessante no uso de aplicativos interativos;
segundo, o descarte de pacotes não ocorrerá em surtos, pois os pacotes são
descartados com uma certa probabilidade pa dada por
pa =pb
(1 − cont.pb)(2.1)
onde cont é o número de pacotes desde o último marcado.
pb = maxp
(avg − minth)
(maxth − minth)(2.2)
onde maxp é a probabilidade máxima que pb pode assumir e avg é o tama-
nho médio da fila.
Na Figura 2.3 pode ser observado que o gerenciamento ativo da fila RED
possui uma função com comportamentos distintos nos intervalos: [0, minth),
[minth, maxth), e [maxth, +∞). No primeiro intervalo, nenhum pacote é des-
cartado, no segundo, pacotes são descartados com uma probabilidade pa e no
terceiro todos os pacotes são descartados.
P
avg
max p
1
min th
th
max th
P : Probabilidade de marcação de pacotes
max p : Probabilidade máxima de marcação de pacotes avg: Tamanho médio da fila min th : Mínimo limiar max th : Máximo limiar
Figura 2.3 Mecanismo RED
Mecanismos para implementação de QoS 42
2.3.2.2
RIO (RED In-Out)
Como se verá no próximo capítulo, o modelo para oferecimento de QoS em
larga escala prevê, além da classificação de serviços, uma classificação de paco-
tes de acordo com sua conformação aos parâmetros de tráfego estabelecidos no
contrato de serviço. A classificação mais simples divide os pacotes em In e Out
dependendo de seu enquadramento no perfil de tráfego. Existente em outros
tipos de rede, esta é uma forma de controle de congestionamento seletiva, pois
em caso de congestionamento os pacotes Out são descartados primeiro.
O esquema denominado RIO usa o mesmo mecanismo utilizado no RED,
porém com dois grupos de parâmetros, um para os pacotes rotulados como In
e outro para os pacotes rotulados como Out. Num roteador implementado com
RIO, o tipo de pacote é previamente verificado. Se o pacote for In, as filas
médias de pacotes In (avgin), e total de pacotes (avgtotal), são calculadas pelo
roteador. Porém, se o pacote for Out, somente a fila média total é calculada. A
probabilidade de se descartar pacotes In depende da avgin, e a probabilidade
de se descartar pacotes Out depende da avgtotal.
Na Figura 2.4 existem três parâmetros para cada classe. Os três parâmetros
In : minin, maxin e maxpin definem os três intervalos do algoritmo RED. No
primeiro [0, minin), nenhum pacote é descartado, no segundo [minin, maxin),
pacotes são descartados com uma probabilidade pain e no terceiro [maxin, +∞)
todos os pacotes são descartados. Similarmente, os parâmetros minout, maxout
e maxpout definem as correspondentes fases dos pacotes Out.
avg in
max p_in
1
min in max in
P in
avg total
max p _out
1
min out max out
P out
Figura 2.4 Mecanismo RIO
Mecanismos para implementação de QoS 43
2.3.2.3
WRED (Weighted RED)
WRED [33] é uma implementação da Cisco que combina as funcionali-
dades do RED com a classificação por precedência IP. Ela suporta até oito
níveis de precedência, onde cada um desses níveis é configurado com distintos
parâmetros RED (Fig. 2.5).
Por ser uma extensão do RED, o gerenciamento ativo de fila WRED tra-
balha de forma semelhante a ele. Porém, no WRED os efeitos se estendem às i
classes. Ou seja, se a fila média se encontrar antes do limiar minth(i), nenhum
pacote da classe i é descartado, se ela estiver no intervalo [minth(i), maxth(i)),
os pacotes da classe i são descartados com probabilidade pa(i) e se avg estiver
acima de maxth(i), todos os pacotes da classe i são descartados.
P
avg
max p (7) 1
min th (7) max th (7) max th (0) min th (0) ......
max p (0)
min th ( i): Mínimo limiar da precedência i max th (i): Máximo limiar da precedência i max p (i): Máxima Probabilidade de
marcação da precedência i
Figura 2.5 Mecanismo WRED
Mecanismos para implementação de QoS 44
2.3.3
Especificação, Policiamento e Conformação de Tráfego
Como já observado, em uma rede com QoS, as características do tráfego e
os parâmetros de QoS devem ser especificados em um contrato de serviço. O
policiamento é uma monitoração do tráfego com o objetivo de verificar se o
mesmo está correspondendo à especificação. A conformação ou modelagem é
um processamento aplicado a um fluxo para que ele apresente características
desejadas.
Em uma rede com QoS, a função de policiamento é fundamental em de-
terminados pontos da rede para evitar que usuários introduzam mais tráfego
do que o permitido pelo contrato. Caso isto aconteça, a rede em geral pode
adotar 2 procedimentos:
• Descartar o tráfego que não está em conformidade ou o define como
elegível para descarte;
• Atrasar o tráfego em excesso, através de mecanismos de enfileiramento,
retendo os pacotes e liberando-os de maneira tal que o fluxo de saída
esteja dentro dos parâmetros definidos.
Ambas as ações podem ser vistas como uma conformação de tráfego.
A técnica de balde de fichas (token bucket), descrita a seguir, é a mais comu-
mente utilizada para as funções de especificação, policiamento e conformação
de tráfego.
2.3.3.1
Balde de Fichas (Token Bucket)
Como descrito em [34] um algoritmo Token Bucket com parâmetros r e b
especifica um fluxo de tráfego tal que, em um intervalo de tempo T não seja
transmitido um número de bytes maior do que
v = b + rT (2.3)
Isto corresponde a um tráfego com taxa constante r que eventualmente possa
ser ultrapassada porém sem ultrapassar o total de bytes permitido para o inter-
Mecanismos para implementação de QoS 45
valo. Supondo que durante um intervalo de tempo ∆t, a taxa de transmissão
tenha um valor p >> r, temos um surto neste intervalo. Note-se que, de
acordo com (2.4) este surto poderá ter mais do que b bytes pois além do b
bytes deve-se considerar a parcela r∆t. Na realidade, o tamanho máximo de
um surto à taxa p será
p∆t = b + r∆t (2.4)
sendo o valor da duração do surto ∆t, obtida desta equação, isto é
∆t =b
p − r(2.5)
O nome Token Bucket se deve ao fato de que a formulação descrita acima pode
ser associada à operação de um balde de fichas. Fichas são depositadas em um
balde, com capacidade para b fichas, a uma taxa constante r. As propriedades
básicas do balde são
• Cada byte transmitido consome uma ficha;
• Quando não houver pacote para transmitir, as fichas acumulam-se no
balde até sua capacidade b, permitindo que se transmita posteriormente
rajadas de pacotes;
• Se o balde enche de fichas, as próximas fichas que chegam são descarta-
das.
A condição (2.4) será violada se um pacote chegar e não houver fichas
em quantidade suficiente no balde para transmiti-lo. Neste caso, na operação
de policiamento, o pacote é declarado não conforme e uma de duas ações
de conformação pode ser tomada: (i) O pacote é descartado; (ii) O pacote é
armazenado num buffer até que se tenha fichas suficientes no balde. Uma outra
alternativa é transmitir o pacote marcando-o como elegível para descarte.
Mecanismos para implementação de QoS 46
r fichas /s
b: Número máximo de Fichas
Fichas ? (N)
(S)
Pacotes
verde
vermelho
Figura 2.6 Arquitetura Lógica do Balde de Fichas
2.3.4
Controle de Admissão e Reserva de Recursos
O controle de admissão é o procedimento que um roteador de entrada de
uma rede usa para determinar se um novo fluxo pode ser admitido na rede com
as garantias de QoS solicitadas. Este procedimento consiste, basicamente, em
verificar se, nas rotas disponíveis, há recursos suficientes para atender os pa-
râmetros do contrato de serviço sem prejuízo das garantias feitas a outros
tráfegos. Se houver recursos suficientes, estes devem ser reservados para o
novo fluxo ao longo da rota selecionada. Caso contrário a solicitação é negada.
Existem diversos algoritmos para implementação de controle de admissão ba-
seados em uma variedade de critérios. Por outro lado, o processo de escolha
de rotas e reserva de recursos exige sinalização específica.
O protocolo de reserva de recursos interage com o roteamento baseado na
qualidade de serviço para estabelecer um caminho através da rede na primeira
instância, e, baseado no mapeamento e controle de admissão da qualidade
em cada módulo de recursos local (CPU, memória, switches, roteadores, etc.),
recursos fim-a-fim são alocados. Um exemplo usual de um protocolo de reserva
de recursos é o RSVP (Resource reSerVation Protocol - RFC 2205). O RSVP é
um protocolo de sinalização que atua sobre o tráfego de pacotes IP numa rede.
O RSVP é eficiente do ponto de vista da QoS na medida que provê granu-
laridade e controle fino das aplicações. Uma questão importante a ressaltar
Mecanismos para implementação de QoS 47
é a granulosidade de fluxos, ou seja, a distinção adotada por alguns dos mo-
delos (IntServ, DiffServ ou mesmo Melhor-Esforço) frente à diversidade de
fluxos presentes. O serviço de melhor-esforço tem granulosidade nula, uma
vez que não há distinção entre os fluxos presentes. Já o modelo DiffServ,
possui uma granulosidade média enquanto que IntServ é dotado de máxima
granulosidade. A maior desvantagem do RSVP é a complexidade inerente a
sua operação nos roteadores que, eventualmente, pode causar dificuldades nos
backbones de grandes redes.