2 Qualidade de Serviço na Internet - DBD PUC RIO · Qualidade de Serviço na Internet ... fontes de variaçªo, de um modo geral, podem ser classi˝cadas em mudanças de cenas, que

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

DBD

PUC-Rio - Certificação Digital Nº 0016489/CA

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

DBD



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

DBD



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

DBD



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

DBD



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

DBD


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-

DBD


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

DBD


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-

DBD


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.

DBD


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.

DBD


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

DBD


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.

DBD


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 ;

DBD


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

DBD


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.

DBD


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.

DBD


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

DBD



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

DBD



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.

DBD



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.

DBD



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.

DBD



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

DBD



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

DBD



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

DBD



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-

DBD



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.

DBD



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

DBD



é 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.

DBD


Documents

2 Qualidade de Serviço na Internet - DBD PUC RIO · Qualidade de Serviço na Internet ... fontes de variaçªo, de um modo geral, podem ser classi˝cadas em mudanças de cenas, que