4. qos - qualidade de serviçofalencar/arquivos-flavio-uerj/redes... · 2020. 7. 21. · uerj 2020...
TRANSCRIPT
-
N O T A S D E A U L A , R E V 9 . 0 – U E R J 2 0 2 0 – F L Á V I O A L E N C A R D O R Ê G O B A R R O S
Redes de Comunicações 2
QoS – Qualidade de Serviço e
Multimídia
Flávio Alencar do Rego Barros Universidade do Estado do Rio de Janeiro
E-mail: [email protected]
Capítulo
5
mailto:falencarrb@
-
UERJ 2020 Redes de Comunicações 2 Pg. 143
Cap. 5 – QoS e Multimídia
Com o crescimento do uso de multimídia através da Grande Rede, as técnicas
tradicionais da Internet (roteamento, confiabilidade na entrega, controle de fluxo,
controle de congestionamento, etc) não se mostraram suficientes para dar as garantias
exigidas de qualidade de serviço (QoS). QoS está associado originalmente a redes
-
UERJ 2020 Redes de Comunicações 2 Pg. 144
Cap. 5 – QoS e Multimídia
orientadas à conexão, pois quando é estabelecido um circuito, se faz a reserva de
recursos da rede. As técnicas que tratarem disto para a Internet deverão privilegiar um
conceito novo: o fluxo. Entenda-se fluxo por uma seqüência de pacotes encaminhados
da fonte emissora para o(s) destino(s), mantendo estes pacotes características
semelhantes e merecendo tratamento também semelhante do núcleo da rede. O alvo
desta forma de pensar a Rede é lidar com multimídia, nas suas diversas formas: mídia
contínua (streaming media), videoconferência, VoIP (voz sob IP), IPTV (TV sob IP),
etc.
Para uma rede não orientada à conexão (como a Internet, que é implementada
pela suíte TCP/IP!), os pacotes pertencentes a um mesmo fluxo podem seguir rotas
diferentes, portanto, nelas devem ser estabelecidas “pseudo-conexões” obtidas por
agregação de pacotes que formem um fluxo. A questão a ser resolvida é:
“Como compatibilizar esta característica da Internet com os quatro parâmetros básicos
de QoS (confiabilidade na entrega com controle de perdas, retardo, jitter e
banda)?”.
Como ilustrado no slide 5-3, conforme a aplicação em questão, as exigências de
QoS são muito diferentes. Enquanto as 4 primeiras (e-mail, transferência de arquivos,
-
UERJ 2020 Redes de Comunicações 2 Pg. 145
Cap. 5 – QoS e Multimídia
acesso Web e login remoto) são exigentes em confiabilidade (sequer um bit pode ser
perdido!), as quatro últimas (todas dependentes de áudio/vídeo) toleram perdas.
Enquanto aplicações que envolvam basicamente transferência de arquivos (download, e-
mail, áudio e vídeo) não são sensíveis ao atraso, pois podem ser retardadas
uniformemente até mesmo alguns segundos, aplicações interativas (login remoto, acesso
Web) já são mais sensíveis ao atraso. Pior ainda, aplicações tempo real (telefonia,
videoconferência) são intolerantes ao atraso. Muitas das aplicações mostradas nada
sofrem com o jitter, mas vídeo, e principalmente, áudio, podem ter resultados
catastróficos. Finalmente, a banda é outro parâmetro de exigências disparatadas: em um
extremo (alta tolerância) temos e-mail e login remoto, noutro, vídeo.
Voltemos ao nosso problema base. O grande número de fluxos no interior da Rede
poderá inviabilizar a introdução de QoS na Internet, pois os roteadores não teriam
capacidade para armazenar estado de cada fluxo, ou tratar cada fluxo diferentemente.
Uma forma simplificada de prover QoS é agregar diversos fluxos em poucas classes de
serviços (CoS), situação que vai exigir que cada pacote carregue no seu cabeçalho a
classe a qual ele pertence.
-
UERJ 2020 Redes de Comunicações 2 Pg. 146
Cap. 5 – QoS e Multimídia
Com o advento do ATM pensava-se resolver estes problemas, pois ele já
pressupunha diferentes classes de serviço como nós já estudamos (CBR, VBR, ABR e
UBR). Porém, por diversas razões, principalmente de ordem econômica, esta tecnologia
não vingou e, provavelmente, não vingará totalmente na Internet, o que induziu a
pesquisa para dotar a Internet, como ela é, de QoS. Algumas outras propostas iniciais
(nenhuma delas, porém, se mostraram plenamente satisfatórias) foram:
1) Sobre-provisionamento: seria simples se se oferecesse uma maior capacidade no
roteador, maiores espaços de buffer e de banda, mas isto é caro e poderia se tornar
inviável (o sistema telefônico usa esta estratégia, observe que dificilmente você deixa
de receber o tom de discagem).
2) Bufferização: esta técnica não afeta a confiabilidade ou a banda, mas aumenta o
atraso (este o seu malefício) e elimina o jitter (este o seu benefício). Portanto, presta-
se a áudio e vídeo sob demanda, mas já não serve para aplicações em tempo real.
O estado atual da pesquisa no assunto tem levado a propostas de conformação e
priorização de tráfego, reserva de recursos, controle de admissão, escalonamento de
pacotes e roteamento consciente de QoS. Este conjunto técnicas tem se abrigado em
duas tecnologias que tem sido conhecidas como IntServ (Serviços Integrados) e
DiffServ (Serviços Diferenciados) que analisaremos.
-
UERJ 2020 Redes de Comunicações 2 Pg. 147
Cap. 5 – QoS e Multimídia
As classes de serviço podem ser implementadas ou baseadas na camada 2
(MAC) através do novo padrão IEEE802.1p, que dá a pacotes de classe mais alta um
tratamento privilegiado, ou então baseadas na camada 3, através da definição de um
comportamento padrão (PHB – per-hop behavior) dispensado a cada classe. Esta última
modalidade parte do TOS (Type of Service), campo que já existe desde o IPv4 (e não
era usado!) e agora é reinterpretado na tecnologia DiffServ. O slide 5-5 resume as
diversas formas de prover alguma QoS na Internet.
Estaremos particularmente interessados em como lidar com multimídia pela
Internet, o que significa uma dentre as três formas seguintes:
a) streaming media armazenada;
b) streaming “ao vivo”;
c) tempo-real, interativo.
Todos eles envolvem parâmetros de QoS.
Por ora, vamos detalhar os tais parâmetros de QoS, os problemas que a Internet
tradicional terá para implementá-los e técnicas introduzidas para resolver tais
problemas.
-
UERJ 2020 Redes de Comunicações 2 Pg. 148
Cap. 5 – QoS e Multimídia
Via de regra, o retardo de processamento (rrPPRROOCC) é desprezível em face dos
outros retardos, e o retardo de fila (rrFFIILLAA) é bastante variável. O retardo de transmissão
(rrTTRRAANNSS) depende do tamanho médio do pacote (PP bits) e da capacidade do enlace (BB
bps) e vale PP//BB segs. Se a distância entre dois roteadores vizinhos é dd metros e a
velocidade de propagação no enlace é de vv metros/seg, o retardo de propagação (rrPPRROOPP)
será de dd//vv segs.
Todos estes retardos (vide slide 5-7) são, via de regra, desprezíveis (ordem de
micro segs) em presença do retardo de enfileiramento, mas não se deve esquecer que
rrPPRROOPP pode alcançar 100´s msegs para enlaces de satélite geoestacionário; rrTTRRAANNSS pode
também alcançar 100´s msegs para pacotes enviados por modems de 28.8 Kbps; rrPPRROOCC
influencia bastante a vazão máxima de um roteador.
Retardo de fila: Seja a taxa média de chegada de pacotes no roteador, então PP é a
taxa média de chegada de bits no mesmo, e, portanto, PP//BB é a intensidade de tráfego
produzida (confira as medidas destes fatores! Sugiro rever também Redes 1, capítulo 2).
Se PP//BB >> 11 significa que a taxa de chegada é maior que a de atendimento (saída), e
o roteador que tenha um buffer limitado (e todos têm!) deverá descartar pacotes.
Se PP//BB 11 significa que o problema é tratável, mas deveremos ainda considerar a
natureza do tráfego.
-
UERJ 2020 Redes de Comunicações 2 Pg. 149
Cap. 5 – QoS e Multimídia
a) Se a chegada de pacotes no roteador é periódica simples (um pacote chega a cada PP//BB
segundos), então não há fila e rrFFIILLAA = 0 !
b) Se pacotes chegam ainda periodicamente, mas em rajadas, o n-ésimo pacote
experimentará retardo de ((nn –– 11))PP//BB segs.
c) Se a chegada é aleatória, o retardo na fila pode variar de desprezível a incontrolável,
como ilustrado no slide 5-8.
Se considerarmos agora que da origem ao destino existem RR roteadores em iguais
condições, as mesmas que o host emissor, o retardo total fim a fim será (demonstre!):
rrTTOOTTAALL == ((RR++11))..((rrPPRROOCC ++ rrTTRRAANNSS ++ rr PPRROOPP)) ++ RR..rrFFIILLAA
-
UERJ 2020 Redes de Comunicações 2 Pg. 150
Cap. 5 – QoS e Multimídia
Para áudio ou vídeo contínuo existe uma solução de compromisso entre retardar
a reprodução dos pacotes de forma fixa e a perda de pacotes, como ilustrado no slide 5-
9. O emissor gera os pacotes a intervalos regulares (em azul). A linha vermelha denota a
chegada dos pacotes (incorporando, como se vê, o jitter). Se for fixado um retardo
menor (p – r) para a reprodução, em contrapartida se perderá o quarto pacote, enquanto
se estabelecermos o retardo maior (p´ - r) para reprodução, nenhum pacote se perderá.
A forma mais natural de lidar com este tradeoff é fazer uma estimativa do retardo e da
variância da rede e ajustar o retardo de reprodução de acordo.
-
UERJ 2020 Redes de Comunicações 2 Pg. 151
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 152
Cap. 5 – QoS e Multimídia
Como mencionamos, o jitter imposto pela rede pode estragar algumas aplicações
como áudio ou vídeo contínuo. Este processo se encontra ilustrado nos slides 5-10 e 5-
11. Considere o exemplo de uma aplicação de áudio que produz “pedaços” de 40ms de
áudio e os envia em datagramas individuais. A seqüência correta e a presteza dos
datagramas tem sentido para a aplicação, mas não tem para a rede IP, que os trata de
modo individual, sem relação entre os datagramas. Não existe nenhuma sinalização no
nível do IP! Não existe nos roteadores nenhum exame do tipo de tráfego que cada
datagrama contém, todos os dados são tratados com igual prioridade, não existe
reconhecimento de perdas ou retardos. Não pode ser garantido que QoS seja oferecido
durante a sessão de comunicação. Para eliminar perdas causadas por jitter imposto pela
rede (imagine áudio contínuo) uma técnica é utilizar um buffer de reprodução e carregar
previamente alguns segundos da mídia comprimida já recebida.
Buffer de reprodução: A partir de certo ponto, o buffer é esvaziado a uma taxa
constante dd (o cliente receptor ouve o áudio) igual à taxa instantânea de chegada xx((tt)),
exceto quando ocorre perda de pacote, ocasião em que xx((tt)) é momentaneamente menor
que dd.
-
UERJ 2020 Redes de Comunicações 2 Pg. 153
Cap. 5 – QoS e Multimídia
Perceba que se usarmos TCP como o transporte, a taxa de entrada xx((tt)) vai
flutuar por causa do slow start e da janela de controle de fluxo, mesmo quando não
existe perda de pacote de áudio! Além disso, o controle de congestionamento do TCP
poderá reduzir a taxa instantânea xx((tt)) a menos que dd por longo período, o que poderá
esvaziar o buffer no receptor e provocar pausas indesejáveis no fluxo de áudio no
cliente. Portanto, o mais indicado é enviar os pacotes de áudio sob o UDP a uma taxa
constante igual a dd.. Neste sentido, existe uma técnica um tanto rígida, Balde Furado,
aonde rajadas de tráfego chegam ao servidor, mas este só libera fluxo a taxa constante
(vide exercício 1-lista 5). Perceba que Buffering é uma técnica a ser usada no lado do
cliente de multimídia, enquanto Balde Furado e Smoothing (veremos logo a seguir)
são técnicas a serem usadas no lado do servidor (diz-se: técnicas de formatação de
tráfego – Traffic Shapping). Veremos o Balde Furado no contexto dos mecanismos de
policiamento, mais à frente.
A técnica de “bufferização” de dados é necessária para lidar com retardo, jitter e
variabilidade de taxa, mas não é suficiente. Ela pode reduzir a perda de pacotes, mas
impõe uma solução de compromisso entre jitter e latência de serviço, além de não dar
respostas às mudanças no perfil do tráfego, podendo levar a situações de esgotamento
-
UERJ 2020 Redes de Comunicações 2 Pg. 154
Cap. 5 – QoS e Multimídia
ou de sobrecarga de “buffer”. Neste sentido são propostas técnicas de planejamento de
transmissão (smoothing) para serem aplicadas na fonte ou em proxies. Na sua essência,
smoothing consiste no planejamento do perfil do tráfego que chega, do início e do
tamanho de “buffer” da transmissão. O escalonamento resultante deste algoritmo é
ótimo e único, além de minimizar a banda requerida, porém, não vale para aplicações de
visualização interativa. Ademais, com smoothing existe a solução de compromisso
entre, de um lado, redução de jitter e suavização do perfil do tráfego, e de outro,
aumento de necessidade de “bufferização”. Por conseqüência, pode-se esperar um
aumento da latência na prestação de serviço, problema a ser minorado, via proxies.
Perdas de pacotes é um problema inerente à rede de datagramas baseada em IP,
pois ela é não confiável. Muitas vezes este problema pode ser resolvido com esquemas
de retransmissão de pacotes a partir da fonte ou de servidores de reparos. Em certos
casos, como em mídia contínua, isto não é adequado. Para não depender de retransmissões,
uma família de propostas aponta para a “dissimulação da falha”, que pode ser feita com
o receptor consumindo de novo o último pacote recebido, ou pode se usar interpolação.
Para reduzir o efeito de perdas em rajadas existe a técnica de interleaving, onde pacotes
-
UERJ 2020 Redes de Comunicações 2 Pg. 155
Cap. 5 – QoS e Multimídia
adjacentes são separados por certa distância. Se de um lado este esquema não consome
banda extra, de outro, introduz latência de reordenamento de pacotes no receptor.
Outra técnica para eliminar o efeito das perdas é incorporar redundância às
informações transmitidas. Para aplicações multimídia, as perdas têm um sentido mais
amplo, trata-se de pacotes que de fato não chegaram, mas pode ser também pacotes que
chegam além do instante destinado para a sua reprodução. A solução de retransmissão
em alguns casos pode não ser conveniente (p.ex., quando o tempo de propagação é
muito alto, imagine de novo o caso de satélites), neste caso usa-se FEC (Forward Error
Correction) ou Entrelaçamento (Interleaving). No mecanismo FEC básico a cada grupo
de nn pacotes de dados se acrescentam kk pacotes de paridade. Se quaisquer nn pacotes são
recebidos com integridade, isto é o suficiente para não haver necessidade de
retransmissão.
-
UERJ 2020 Redes de Comunicações 2 Pg. 156
Cap. 5 – QoS e Multimídia
Outro exemplo: deseja-se transmitir três pacotes (nn == 33) pacotes de dados:
D1 = 1 0 1 0 1 0 1 0
D2 = 1 1 1 1 0 0 0 0
D3 = 1 1 1 0 1 0 1 1, então é produzido um pacote de paridade (kk == 11):
P1 = D1 D2 D3 = 1 0 1 1 0 0 0 1
Se dos 4 pacotes enviados chegaram 3:
P1 D2 D3 = 1 0 1 0 1 0 1 0 pacote D1 recuperado!
P1 D1 D3 = 1 1 1 1 0 0 0 0 pacote D2 recuperado!
D1 D1 D2 = 1 1 1 0 1 0 1 1 pacote D3 recuperado!
Naturalmente, se aumenta a redundância, aumenta a probabilidade de recuperação, mas
também aumenta o tráfego gerado (overhead).
Obs: O símbolo ssiiggnniiffiiccaa uummaa ooppeerraaççããoo ddee oouu--eexxcclluussiivvoo ((XXOORR))..
-
UERJ 2020 Redes de Comunicações 2 Pg. 157
Cap. 5 – QoS e Multimídia
Em um segundo mecanismo de FEC se transmite um fluxo (p. ex., de áudio) de
menor qualidade como informação redundante (o fluxo original, p. ex., é codificado
com PCM a 64 Kbps e o fluxo redundante com GSM a 13 Kbps) como ilustrado no
slide 5-17. Assim, sempre que exista uma perda de pacote (não consecutiva), o receptor
pode conciliar a perda com um bloco (de mais baixo nível) incorporado no pacote
seguinte. Observe que o receptor tem que bufferizar dois pacotes antes de reproduzir o
áudio.
O aumento na taxa de transmissão nesta última modalidade de FEC é proporcional à
relação das taxas de transmissão de maior e de menor qualidade (no exemplo
PCM/GSM acima o aumento é de aproximadamente 20%, degradando-se mais o fluxo
de redundância, diminui-se mais ainda o acréscimo de taxa de transmissão). No
mecanismo básico de FEC este aumento é proporcional ao inverso do número de
pacotes originais transmitidos antes que se transmita paridade, ou seja, no exemplo do
slide 5-16 este aumento seria de 33%.
Observe também que este segundo esquema de FEC já não será atrativo para perdas em
rajadas (burst).
-
UERJ 2020 Redes de Comunicações 2 Pg. 158
Cap. 5 – QoS e Multimídia
Com a técnica de entrelaçamento (interleaving) se reduz o efeito de perdas de
pacotes separando pacotes adjacentes, com isto distribuindo-se as perdas entre os
diversos blocos. Isto melhora sensivelmente, por exemplo, a qualidade percebida de um
fluxo de áudio (acontece uma degradação suave, não abrupta) sem que se aumente o
requisito de banda. O preço a ser pago por esta técnica é aumentar a latência, coisa pode
ser danosa para aplicações interativas como, por exemplo, telefonia pela Internet.
Outras técnicas são também utilizadas, como, por exemplo, aquelas orientadas a
recuperação a partir do receptor por:
- repetição (reproduzindo o pacote anterior antes da perda): é mais simples, porém de
pouca qualidade;
- interpolação (ajustando a reprodução da perda pela média de dois pacotes
consecutivos recebidos): mais complexa, de maior qualidade.
-
UERJ 2020 Redes de Comunicações 2 Pg. 159
Cap. 5 – QoS e Multimídia
O uso de proxies em aplicações de mídia contínua se destina a reduzir tanto a
banda requerida dos servidores e rede, quanto à latência de startup nos clientes. Existem
vários grupos de propostas baseadas em proxy: as que dividem o vídeo comprimido em
camadas; as que propõem armazenar em cache certa parte do vídeo; as que propõem
combinar alguma destas duas estratégias com aquelas técnicas de compartilhamento de
recursos. No grupo de divisão de vídeo por camadas, a idéia principal é armazenar em
cache um número tal de camadas que o cliente possa se adaptar recebendo uma ou mais
camadas, uma camada com todo vídeo na sua qualidade básica, as outras agregando
progressivamente qualidade ao vídeo recebido pelas camadas anteriores, conforme sua
disponibilidade de recursos. No grupo que propõe armazenar em cache porções do
vídeo, a técnica mais popular é o Proxy Prefix Caching (PPC), com o armazenamento
em cache do início do stream (prefixo), de forma que quando o cliente pede um stream,
o proxy lhe entrega com rapidez o “prefixo” e, simultaneamente, requisita e recebe do
servidor o restante do stream preenchendo o seu segundo “buffer” para viabilizar
entrega posterior ao cliente. Uma forma alternativa de distribuição de multimídia é dada
por CDN (Content Distribution Network). A empresa de CDN instala centenas de
servidores CDN por toda Internet, clona o conteúdo de seus clientes produtores de
-
UERJ 2020 Redes de Comunicações 2 Pg. 160
Cap. 5 – QoS e Multimídia
conteúdo nestes diversos servidores. Além disto, a empresa CDN provê um mecanismo
semelhante ao (e apoiado por) serviço de servidor de nomes (DNS) de modo que o
cliente acessa o conteúdo em um servidor CDN que esteja mais perto do cliente (ou que
tenha menos congestionamento).
Tempo Real:
Para lidar com aplicações interativas em tempo real (telefonia IP, videoconferência, etc)
existem soluções representadas por RTP, SIP e H.323. Vejamos RTP (RFC 1889) –
Real Time Protocol. RDP roda sobre UDP e a idéia é formar uma corrente de pacotes
RTP com suas legendas de tempo (time-stamp) que facilitam a interação de redes
multimídia. Observe que RTP não fornece nenhum mecanismo que garanta a entrega de
dados a tempo, nem fornece outras garantias de QoS. Sequer garante que os pacotes
serão entregues em ordem. O EFC 1889 especifica também o protocolo RTCP para ser
usado junto com RTP.
-
UERJ 2020 Redes de Comunicações 2 Pg. 161
Cap. 5 – QoS e Multimídia
Atenção: Áudio e video streamed, que apresente baixo retardo, baixo jitter, baixa perda
e alto data rate são características desejáveis para aplicação “tocar” a partir de um
fluxo, mas, somente o último (data rate) é significativamente importante e pode ser
considerado um requisito QoS crucial para estas aplicações. Jitter e perdas podem ser
compensados tendo um grande buffer no receptor. Áudio e vídeo real-time
normalmente envolvem seres humanos como sujeitos do fluxo de áudio/vídeo, de modo
que retardo e jitter devem ser mantidos por volta de 200 ms (retardo máximo menor que
400 ms), acrescente-se ainda a necessidade de sincronização entre estes dois fluxos.
RTP (RFC1889) é usado para transportar formatos públicos ou proprietários de
áudio (WAV, GSM) ou de vídeo (MPEG1, MPEG2) em tempo real, e o faz no topo de
UDP pelas razões que recentemente verificamos. Este é o protocolo decano pra
multimídia pela Internet e é destinado tanto para unicast, quanto para multicast. Ao
RTP está associado um protocolo simples de sinalização no nível da aplicação, o Real
Time Control Protocol (RTCP). O conjunto RTP/RTCP permite passar informação
de recurso em uso, parâmetros de QoS do fluxo e outras informações entre emissores e
receptores. Atenção: RTP/RTCP não oferecem, eles próprios, controle de QoS ou
reserva de recursos! Seriam necessários outros protocolos para dar as garantias de QoS.
-
UERJ 2020 Redes de Comunicações 2 Pg. 162
Cap. 5 – QoS e Multimídia
Seu cabeçalho (do RTP) indica o tipo de codificação feito (p. ex., PCM,
modulação delta, para áudio; JPEG, MPEG1, para vídeo), um campo com o número de
seqüência, o campo timestamp, que reflete o instante de amostragem do primeiro byte
no emissor e o campo SSRC que oferece a identificação do emissor para cada fluxo
criado.
-
UERJ 2020 Redes de Comunicações 2 Pg. 163
Cap. 5 – QoS e Multimídia
O protocolo RTCP transporta apenas sinalização e é circulado entre os diversos
participantes da sessão UDP com o objetivo de oferecer estatísticas úteis para a
aplicação, tais como: o número de pacotes enviados, o número de pacotes perdidos, o
jitter entre chegadas. Estas informações de feedback podem ser usadas pelo emissor
para ajustar a sua taxa de transmissão, ou pelos receptores para propósitos de
diagnósticos.
Uma parte importante do RTP é seu suporte para tradução (ou seja, mudar a
codificação de um fluxo em uma estação intermediária) ou para mistura (ou seja,
receber fluxos de dados de várias origens, combinando-os em um único fluxo e
enviando o resultado). Por fim, RTP é especialmente projetado para operar com
multicasting IP, através de sua característica de mistura: numa videoconferência, por
exemplo, todas as fontes emissoras podem difundir para um mixer, que combina os
dados de cada um em único fluxo antes do multicasting.
Detalhemos agora o RTP e o RTCP.
-
UERJ 2020 Redes de Comunicações 2 Pg. 164
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 165
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 166
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 167
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 168
Cap. 5 – QoS e Multimídia
Mesmo que tenhamos até aqui analisado diversas técnicas que se propõem
conferir QoS pela Internet, todas elas ficam, no entanto, limitadas pelo serviço melhor
esforço oferecido pela suíte TCP/IP, ou seja, não existe nenhum tratamento diferencial
no interior da Rede para pacotes multimídia ou qualquer um outro. As alternativas
genéricas consideradas são duas:
1) Introduzir uma sinalização específica que ofereça QoS. Esta proposta é adotada pela
Arquitetura de Serviços Integrados (IntServ) e pelo roteamento consciente de QoS;
2) Redefinir o campo TOS (Type Of Service) do IP no sentido de permitir aos
roteadores oferecerem um serviço padrão baseado nestes bits. Neste caso, estamos
falando dos Serviços Diferenciados (DiffServ).
Veremos ambos a seguir.
-
UERJ 2020 Redes de Comunicações 2 Pg. 169
Cap. 5 – QoS e Multimídia
Vamos esclarecer estes princípios associando um exemplo ao atendimento de
cada um deles.
-
UERJ 2020 Redes de Comunicações 2 Pg. 170
Cap. 5 – QoS e Multimídia
No exemplo ilustrado no slide 5-36, suponha dois fluxos de pacotes originados
nos hosts H1 e H2 e tendo como destino os hosts H3 e H4, respectivamente, os dois
primeiros hosts em uma LAN, os dois últimos em outra LAN, ambas LANs
compartilhando um enlace de 1.5 Mbps, com o roteador R1 agregando tráfego das duas
fontes através do enlace.
Suponha agora uma aplicação de áudio de 1 Mbps em H1 e uma transferência
de arquivo por FTP em H2. Naturalmente os pacotes de áudio devem ser priorizados,
pois os de FTP não tem restrições de tempo real. Portanto, cada pacote de cada um dos
tráfegos deverá ser marcado de acordo e receber o tratamento adequado no roteador R1.
Isto equivale ao raciocínio base do Princípio 1 que enunciaremos.
Se agora, o tráfego de áudio fosse mal comportado (devido às falhas ou a
comportamento malicioso, não importa!) e tentasse transmitir a 1.5 Mbps, seria
desejável impedir tal situação. Isto nos leva ao Princípio 2.
-
UERJ 2020 Redes de Comunicações 2 Pg. 171
Cap. 5 – QoS e Multimídia
Para obter isolamento existem dois enfoques.
No primeiro, um mecanismo de policiamento poderia ser desenvolvido no
roteador (R1) permitindo a ele tomar alguma ação se necessário (descartar pacotes, por
exemplo) de modo que o tráfego que entra no roteador é moldado segundo algum
critério. Outro enfoque é alocar uma determinada quantidade de banda para cada
tráfego. No exemplo, a aplicação de áudio “veria” uma banda de 1.0 Mbps e o tráfego
FTP “veria” uma banda de 0.5 Mbps. Evidentemente este último enfoque implica
tomar providências de escalonamento de pacotes no nível do enlace.
Suponha agora que a partir de certo instante cessa temporariamente a aplicação
de áudio. Se valesse estritamente o último enfoque abordado, o FTP estaria usando 0.5
Mbps e estaria sendo desperdiçado 1.0 Mbps de banda não utilizada pela aplicação de
áudio que cessou. Isto nos leva ao Princípio 3 enunciado no slide 5-39.
-
UERJ 2020 Redes de Comunicações 2 Pg. 172
Cap. 5 – QoS e Multimídia
Suponha agora dois tráfegos de áudio, ambos de 1 Mbps concorrendo pelo
enlace de 1.5 Mbps. Evidentemente nenhum deles conseguiria a QoS desejada, mesmo
aplicados os princípios anteriores. Não há como resolver o problema e cada tráfego
teria, no máximo, 0.75 Mbps permanentemente. Isto nos leva ao Princípio 4, certamente
uma das sessões não deveria ser admitida (à semelhança com o bloqueio de chamadas,
que é raro, mas pode existir no sistema telefônico).
-
UERJ 2020 Redes de Comunicações 2 Pg. 173
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 174
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 175
Cap. 5 – QoS e Multimídia
Enlaces WAN através de redes ATM são adequados para garantir QoS, pois
ATM já pressupõe diferentes tipos de conexões (CBR, VBR, ABR, UBR). Como
ATM permite estabelecer circuitos virtuais comutados, ele aumenta a flexibilidade dos
fluxos que cruzam a WAN. Entretanto, nem sempre ATM é usado, por problemas de
disponibilidade e custo. Várias soluções destinadas a “casar” ATM com IP são
oferecidas (IPOA, LANE, MPOA), nenhuma, porém, conseguiu ultrapassar aquelas
limitações. A comunidade de pesquisadores da Internet tem trabalhado nas tecnologias
IntServ e DiffServ, mas alguns fabricantes de roteadores têm desenvolvido uma nova
tecnologia de construir rotas chamada MPLS (MultiProtocol Label Switching), que
recupera idéias de construção de rotas como feitas por redes orientadas a circuito. Em
essência, MPLS gera um rótulo curto que atua como uma representação do pacote IP,
de modo que a rede MPLS tem todo um tratamento sobre este rótulo. De certa forma,
pode-se pensar em MPLS como uma tecnologia que facilita o casamento entre IP e
ATM.
Em se tratando de LANs, além das soluções proprietárias, a solução padrão virá
da especificação IEEE802.1p, com a QoS sendo oferecida no nível do acesso ao meio
(MAC).
-
UERJ 2020 Redes de Comunicações 2 Pg. 176
Cap. 5 – QoS e Multimídia
Além de QoS em LANs e backbones, devemos ainda discutir as questões
relativas à QoS referentes a redes de acesso.
Visão geral do MPLS: O rótulo MPLS é colocado entre os cabeçalhos das camadas 2
(PPP, por exemplo) e 3 (IP, por exemplo), e por isto mesmo MPLS é independente de
ambas camadas (pense em termos de uma camada “2.5”). Isto significa que switches
MPLS podem encaminhar pacotes IP ou células ATM, daí o nome Multiprotocol.
Quando um pacote MPLS chega a um roteador MPLS, o rótulo é usado para indexar
uma tabela para determinar a linha de saída e o novo rótulo a sair, portanto, MPLS atua
de forma similar aos circuitos virtuais (porém não existe aqui a etapa de call setup!).
Diferente também de circuitos virtuais tradicionais, aqui os roteadores MPLS agrupam
diferentes fluxos que terminarão em determinado roteador ou LAN com um mesmo
rótulo (diz-se que tais fluxos pertencem à mesma FEC – Forward Equivalence Class),
vale dizer, os pacotes destes agregados são tratados da mesma forma, pertencem à
mesma classe de serviço. Existem duas maneiras de criar a tabela de encaminhamento
MPLS, na primeira, método baseado em redes baseadas em ATM, pacotes que chegam
ao primeiro roteador MPLS no caminho fazem com que este “pergunte” ao roteador
downstream por um rótulo para o fluxo. Este método é aplicado recursivamente até o
-
UERJ 2020 Redes de Comunicações 2 Pg. 177
Cap. 5 – QoS e Multimídia
roteador MPLS final, ou seja, é criado um circuito virtual sob demanda. Para redes não
baseadas em ATM, com a chegada do pacote, o roteador MPLS verifica em que rotas
ele deve encaminhar o pacote e cria uma FEC para cada uma destas rotas avisando-as a
seus roteadores vizinhos, assim sucessivamente até que todos roteadores tenham
adquirido o caminho. Os recursos são reservados à medida que o caminho é produzido
para garantir a QoS apropriada (vide também o exercício 9-lista 5).
Vamos agora nos debruçar sobre as questões de QoS especificamente para as
redes locais (LANs) cabeadas. Já sabemos que a Ethernet, quando foi proposta, nada
tinha que tratasse de QoS. Acréscimos feitos posteriormente ao padrão IEEE802.3
tentam ultrapassar estas limitações.
O padrão IEEE802.1p estende o quadro IEEE802 de modo a incorporar a
priorização de tráfego e o identificador de LAN virtual, como mostra o slide 5-46, com
um tag de 32 bits acrescentado a um quadro IEEE802. Caso o switch implemente o
padrão IEEE802.1p (ele é capaz de decodificar o campo Ethertype = 81.00hex), os bits
de priorização e identificação de VLAN são processados, caso contrário, o switch
descarta o quadro. Tal switch IEEE802.1p possui um classificador que decide o tipo de
-
UERJ 2020 Redes de Comunicações 2 Pg. 178
Cap. 5 – QoS e Multimídia
tráfego (caso não venha explícito no próprio quadro) baseando-se no tipo de protocolo
transportado (em redes IP, combinando endereço fonte e destino, e portas TCP ou
UDP. Neste caso, como o switch vai inspecionar o tipo de quadro, ele é chamado switch
L3 ou switch L4) e aloca o quadro em uma das setes filas de precedência. A seguir, o
escalonador decide que quadro será transmitido de modo a garantir o nível de qualidade
adequado ao tipo de tráfego. Os quadros IEEE802 podem ser marcados no núcleo, nas
bordas ou nas estações (já existem interfaces de rede – NIC – com esta capacidade).
O tipo de serviço oferecido é “melhor que melhor-esforço”, apesar de não dar
garantias de atraso e jitter, melhora as aplicações em LANs que já oferecem banda
razoável e baixo atraso. Numa LAN Ethernet, por exemplo, torna o CSMA-CD mais
“determinístico” para aplicações em tempo real. Mais detalhes sobre extensões ao
IEEE802 ver em:
ISO/IEC 15802-3, “Information technology – Telecommunications and Information
Exchange Between Systems – Local and Metropolitan Area Networks - Common
Specifications – Part 3: Media Access Control (MAC) Bridges: Revision”,
1998
-
UERJ 2020 Redes de Comunicações 2 Pg. 179
Cap. 5 – QoS e Multimídia
Uma situação típica consiste de LANs corporativas espalhadas geograficamente
de modo que precisam de interligação via WAN pública ou privada. Daí surgem
problemas para garantias de QoS entre estas diversas LANs. PPrriimmeeiirroo, se dois
computadores tem comunicação de alto desempenho se estão numa mesma LAN, tal
desempenho cairá de ordens de grandeza se entre eles houver uma WAN. OOuuttrroo
pprroobblleemmaa é que se IEEE802.1p provavelmente será padrão para QoS em LANs, não se
prevê um único padrão para WANs, o que pode favorecer soluções proprietárias. O
tteerrcceeiirroo problema é que enquanto WAN utiliza policiamento de tráfego no ingresso para
verificar conformidade com contratos pré-estabelecidos, equipamentos de LAN para
interconexão com WANs fazem condicionamento de tráfego para ingresso na WAN.
Ora, condicionamento de tráfego é feito via bufferização, o que contribui para
degradação de parâmetros de QoS como retardo e jitter. A solução natural, mas ainda
não devidamente especificada, seria mapear parâmetros de QoS da rede corporativa (p.
ex., precedência IEEE802.1p) em precedência do lado da WAN (p. ex., classes de
serviço DiffServ). Atualmente tabelas estáticas de mapeamento são consideradas mais
viáveis.
Agora que vimos parâmetros de QoS e técnicas adaptadas à Internet
convencional, vimos também as tecnologias que tentam acrescentar conceitos de QoS
nas diversas áreas de rede, voltemos nossa atenção especificamente para multimídia
pela Internet. Recorde que teremos que lidar com três formas de multimídia: streaming
armazenado, streaming “ao vivo” e tempo real interativo.
-
UERJ 2020 Redes de Comunicações 2 Pg. 180
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 181
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 182
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 183
Cap. 5 – QoS e Multimídia
Antes de entrarmos propriamente nas soluções de QoS (IntServ e DiffServ),
como o nosso interesse é especificamente multimídia, vejamos brevemente a questão de
compressão de dados para áudio e vídeo, também o que seria a infra-estrutura mais
conveniente (camada de transporte), e um protocolo de fluxo contínuo para tempo real,
RTSP – Real-Time Streaming Protocol.
-
UERJ 2020 Redes de Comunicações 2 Pg. 184
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 185
Cap. 5 – QoS e Multimídia
Os usuários de multimídia pela Internet gostariam de ter a mesma funcionalidade
do tempo em que se alugava um filme em DVD e se podia assisti-lo com as funções de
pausa, reposicionamento (rápido ou lento) na mídia, avançando ou atrasando. O
protocolo RTPS faz isto, mas não define o:
esquema de compressão;
encapsulamento de (áudio, vídeo);
modo de transporte (UDP ou TCP);
modo como se armazena o áudio/vídeo.
Portanto, RTPS é um protocolo “fora da banda”, enquanto o fluxo de mídia é enviado
“dentro da banda”. RTPS usa porta 544, o fluxo da mídia usa uma porta diferente.
No slide a seguir se apresenta um resumo das mensagens RTPS juntamente com o
pedido de mídia (via HTTP GET) e o fluxo de mídia, todos estes com os elementos
participantes da sessão multimídia.
-
UERJ 2020 Redes de Comunicações 2 Pg. 186
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 187
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 188
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 189
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 190
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 191
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 192
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 193
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 194
Cap. 5 – QoS e Multimídia
O objetivo da Arquitetura de Serviços Integrados (IntServ) é estender o modelo
da arquitetura original da Internet (que foi concebido para suportar apenas serviço
“melhor-esforço” IP) através de 2 elementos: um modelo de serviço estendido (IS –
Integrated Service) e um framework para suportar este modelo.
O modelo IS se compõe das classes de serviço garantido e serviço de carga controlada,
ambos devendo operar em unicast e multicast. O escopo aqui é de garantias de QoS por
conexão.
-
UERJ 2020 Redes de Comunicações 2 Pg. 195
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 196
Cap. 5 – QoS e Multimídia
Para suportar tráfego em tempo-real via serviço garantido é necessário
mecanismos de reserva de recursos (os roteadores deverão ser capazes de reservar
recursos de buffer e de banda) e de controle de admissão. Para isto, inicialmente existe
uma sinalização de chamadas (desenvolvida pelo protocolo RSVP – Resource
reSerVation Protocol) onde cada roteador verifica se dispõe daqueles recursos
solicitados naquele momento.
O uso de um serviço por uma sessão requer a determinação de Tspec (Traffic
specification), que especifica as características esperadas do tráfego (fluxo) daquela
sessão, e a determinação de Rspec (Resource specification). Um Serviço de Carga
Controlada requer Tspec, mas não Rspec; um Serviço Garantido requer ambos.
Tspec é definida em termos de um filtro “balde de fichas” que tem os seguintes
elementos:
rr: o data rate (em bytes/seg);
bb: o tamanho do “balde” (em bytes)
Ele especifica que o fluxo não deve enviar mais de (rrtt ++bb) bytes de dados em tt
segundos. Esta informação pode ser usada pela rede para:
CCoonnttrroollee ddee aaddmmiissssããoo: para testar se o serviço e o perfil de tráfego especificado pode ser
efetivamente honrado ao longo do caminho da rede requisitado;
-
UERJ 2020 Redes de Comunicações 2 Pg. 197
Cap. 5 – QoS e Multimídia
PPoolliicciiaammeennttoo: para assegurar que a aplicação/usuário não exceda a especificação de
tráfego pedida e para tomar a medida apropriada (marcação/descarte de pacotes,
redução do nível de serviço de alguns pacotes).
As especificações Tspec e Rspec possibilitam elementos da rede ter valores
locais dos parâmetros de INTSERV. Quando um caminho para um fluxo/sessão é
selecionado, os valores compostos para um parâmetro são combinados.
SSeerrvviiççoo GGaarraannttiiddoo: Dá garantias de banda e de retardo, tendo o efeito de um circuito
dedicado, mas não dá garantias de jitter.
Rspec é definida em termos de dois parâmetros:
RR: a taxa de serviço requerido. RR deve ser maior ou igual a rr, mas se definir um
valor maior para RR aumenta o retardo total do caminho;
SS: a taxa de “frouxidão” dos limites do retardo. SS deve ser não negativo, mas se
definir um valor maior para SS, de um lado torna mais provável de o pedido de
reserva acontecer, de outro, torna maior o retardo fim-a-fim.
Com os valores de Tspec e Rspec é possível avaliar o limite superior para retardo fim-
a-fim (o limite inferior equivale a não haver pacotes concorrentes e é mais fácil) para o
Serviço Garantido, usa-se para isto o modelo de fluidos, mas este nível de detalhe foge
-
UERJ 2020 Redes de Comunicações 2 Pg. 198
Cap. 5 – QoS e Multimídia
do escopo deste curso.SSeerrvviiççoo CCaarrggaa--CCoonnttrroollaaddaa: Sem garantias, mas numa sessão
deve-se esperar que um percentual muito alto de seus pacotes não será descartado e que
o retardo em filas será próximo de zero. A QoS oferecida teria efeito semelhante aquela
QoS oferecida por uma rede sem carga. Se comparado com a Internet hoje, esta suporta
aplicações multimídia desde que a rede esteja sem carga, mas degrada rapidamente
quando a rede se torna mais carregada. Portanto, este serviço oferece um serviço não
pior que o “melhor-esforço” tradicional.
A sinalização de reserva de recursos de rede (para QoS destinado a aplicações
multimídia) ao longo do caminho origem:destino é feita pelo protocolo RSVP. As duas
características principais do RSVP são:
1. Ele fornece banda em árvores multicast (unicast é considerado um caso
multicast degenerado);É orientado ao receptor: é o receptor do fluxo quem inicia
e mantém a reserva de recursos para aquele
fluxo.
-
UERJ 2020 Redes de Comunicações 2 Pg. 199
Cap. 5 – QoS e Multimídia
Para fazer a reserva de recursos o RSVP inicia com a fonte emitindo a adequada
especificação de fluxo para um endereço multicast (classe D) através de uma mensagem
Path anunciando os requisitos de QoS da sessão. Todos roteadores RSVP encaminham
o Path mantendo soft-state – informação sobre a reserva de recursos requerida – até que
um dos seguintes eventos aconteça: um PathTear é enviado da fonte cancelando a
reserva, uma mensagem Resv é transmitida por algum receptor confirmando a reserva,
ou acontece o timeout do soft-state. Uma mensagem Resv de um receptor é enviada de
volta através da mesma rota que veio a mensagem Path, estabelecendo assim a reserva e
então a aplicação começa a enviar pacotes de dados. Mensagens Path e Resv são
enviadas pela fonte emissora e pelo(s) receptor(es), respectivamente, durante todo
tempo de vida da sessão para “refrescar” o soft-state e manter a reserva. Uma
mensagem PathTear ou ResvTear explicitamente retira a reserva e libera os recursos. É
possivel modificar a reserva durante o tempo da sessão e RSVP pode ser usado para
sessões unicast ou multicast. Como é possível também anunciar valores compostos de
parâmetros QoS.
Para comunicação multicast é possível para um roteador fundir duas reservas para um
mesmo fluxo ao invés de fazer duas reservas separadas.
-
UERJ 2020 Redes de Comunicações 2 Pg. 200
Cap. 5 – QoS e Multimídia
Existem 3 estilos de reservas permitidas em RSVP:
• filtro fixado (FF): este estilo estabelece uma reserva distinta por fonte emissora que
requeira e especifica explicitamente o conjunto de emissores que possam fazer uso desta
especificação de reservas.
• filtro curinga (WF): permite reservas compartilhadas para emissores, mas os
emissores não são explicitamente especificados.
• compartilhamento explicito (SE): permite reserva compartilhada entre emissores
explicitamente especificados.
Estas informações (FF e SE) são portadas no campo FilterSpec dentro da
mensagem Resv fornecida pelo emissor.
É possível a um roteador RSVP fundir reservas de mesmo estilo de modo a passar
upstream uma única reserva, que é o máximo de reservas que podem entrar. Este
procedimento é específico para multicast, onde muitos fluxos para o mesmo grupo são
fundidos.
FF deve ser usado somente para comunicação unicast.
-
UERJ 2020 Redes de Comunicações 2 Pg. 201
Cap. 5 – QoS e Multimídia
WF deve ser usado para conferência aberta, onde o número de emissores e quem eles
são não é conhecido a priori.
SE deve ser para uma situação similar a WF, mas a conferência deveria ser fechada,
com os emissores conhecidos previamente e listados em FilterSpec.
Devemos olhar com “reservas” as reservas do RSVP, pois:
1. Intuitivamente, para redes intensamente utilizadas (como a Internet!) e com recursos
limitados, é esperável que pedidos de reservas muito grandes são menos prováveis de
serem aceitas que reservas menores. Durante o estabelecimento de reservas se o
primeiro passo de cada um de dois pedidos são enviados ao mesmo elemento de rede,
se um dos pedidos é “superconjunto” do outro, o menor pode ser rejeitado
(dependendo dos recursos disponíveis), mesmo se o maior eventualmente não
conseguir também completar (claro que é possível pedir reserva de novo!).
2. Se o primeiro passo da reserva termina com sucesso, o roteador deve manter uma
quantidade considerável de estado de cada receptor que queira se juntar ao fluxo
como, por exemplo, em uma conferência multicast.
3. Os roteadores devem se comunicar com receptores para “refrescar” o soft-state,
gerando tráfego extra, ou senão a reserva vai expirar (timeout).
-
UERJ 2020 Redes de Comunicações 2 Pg. 202
Cap. 5 – QoS e Multimídia
4. Heterogeneidade completa não é suportada. Em uma conferência todos compartilham
o mesmo nível de serviço (garantido ou carga controlada).
5. Se um roteador participante do caminho da reserva falha, vai haver troca de rota IP,
então as reservas RSVP falham e a comunicação passa a ser em serviço “melhor-
esforço”, com os outros roteadores mantendo reservas originais até que mensagens
explícitas ou timeout ou ainda a reserva possa ser estabelecida no novo caminho.
6. As aplicações devem ser conscientes de RSVP, o que atualmente não é trivial!
-
UERJ 2020 Redes de Comunicações 2 Pg. 203
Cap. 5 – QoS e Multimídia
Sobre DIFSERV existem dois documentos básicos:
RFC2474 – descreve valores especiais a serem usados para o campo ToS do IPv4 ou o
campo classe de tráfego do IPv6 quando se usar DIFFSERV.
RFC2475 – descreve a arquitetura DIFFSERV.
DIFFSERV oferece um mecanismo de QoS relativamente simples que pode ser
desenvolvido em redes sem que se precise mudar a operação das aplicações das estações
finais. O mecanismo de QoS é baseado em marcar pacotes um padrão de bits pequeno e
fixo, que mapeia para certos critérios de manipulação e encaminhamento a cada hop. O
Grupo de Trabalho correspondente (WG-DIFFSERV) busca identificar um conjunto
comum de tais comportamentos per-hop, tanto quanto marcações de pacotes para
identificar estes comportamentos.
O modelo DIFFSERV é diferente de INTSERV. Uma diferença chave do
modelo DIFFSERV é que ele é ajustado a um modelo de operação de negócios,
baseado em limites administrativos, com serviços alocados para usuários ou para grupos
usuários.
-
UERJ 2020 Redes de Comunicações 2 Pg. 204
Cap. 5 – QoS e Multimídia
Os mecanismos DIFFSERV devem ser mais simples de implementar que
mecanismos INTSERV e admitirão algum controle de QoS para aplicações antigas que
não são conscientes de QoS.
O modelo de reserva de recursos desenvolvido pelo RSVP implica manter
estado no roteador de cada fluxo que por ele passa. Se pensarmos que medidas feitas em
enlaces OC-3 mostraram acima de 250.000 pares fonte-destino por minuto em roteador
de backbone, fica claro que esta solução não é escalável. Também a natureza das classes
de serviço INTSERV não dá a flexibilidade desejável de transferir ao usuário o nível de
preferência por determinado fluxo. Por outro lado, a arquitetura DIFFSERV oferece a
escalabilidade transferindo a complexidade para as bordas e deixando o núcleo o mais
simples possível, também oferece flexibilidade no sentido que não define classes de
serviços ou serviços específicos, e sim componentes funcionais onde tais serviços
poderão ser construídos.
No cenário simples mostrado no slide 5-84 os pacotes enviados por H1 para H3 pode
ser marcado em R1, enquanto pacotes enviados de H2 para H4 podem ser marcados em
R2. A marca que um pacote recebe (complexidade e decisões sofisticadas são feitas na
borda) identifica a classe de tráfego ao qual ele pertence. Classes de tráfego diferentes
-
UERJ 2020 Redes de Comunicações 2 Pg. 205
Cap. 5 – QoS e Multimídia
receberão serviços diferentes no núcleo da rede onde serão tão somente encaminhados
(o serviço recebido no núcleo é simples). Se os pacotes de H1 para H3 são marcados de
forma igual aos pacotes de H2 para H4, então qualquer pacote no núcleo é agregado e
tratado igualmente, não importa se vem de uma ou outra fonte. Portanto, os roteadores
do núcleo não precisam manter estado de pares individuais fonte-destino!
O trabalho do DIFFSERV é destinado a fornecer uma maneira de estabelecer
QoS usando políticas que formam parte de um acordo de nível de serviço entre o
usuário e o fornecedor do serviço. Tal política pode usar vários campos do cabeçalho
para classificar o pacote, mas a marcação de identificação (feita na borda da rede) pode
ser tão simples quanto um identificador – o byte DS (differentiated services) – dentro
do cabeçalho do pacote. O byte DS será usado no lugar do campo ToS (Type of Service)
nos pacotes IPv4 ou o campo classe de tráfego nos pacotes IPv6, tendo a mesma
sintaxe em ambos casos.
-
UERJ 2020 Redes de Comunicações 2 Pg. 206
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 207
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 208
Cap. 5 – QoS e Multimídia
A idéia é que a interpretação dos DS codepoints e a correspondente
manipulação dos pacotes fiquem sujeitas a algum acordo localmente estabelecido
(SLA). Podem existir SLAs entre cliente e ISP, mas também entre ISPs. Os DS
codepoints são usados para identificar pacotes que tenham o mesmo comportamento
agregado (PHB, per-hop behaviour) com respeito a como eles são tratados por
elementos individuais de rede. As definições de PHB e dos DS codepoints usados
poderá diferir entre ISPs, de modo que necessitará mecanismos de translação entre
ISPs. Perceba que PHB só faz sentido em conjunto. Se um PHB define X% de banda
para um certo tráfego, são necessários outros PHBs para definir como a banda restante é
manipulada.
Um classificador de tráfego seleciona pacotes ou baseado em DS codepoint, ou
em alguma composição de campos do cabeçalho e direciona-os para um condicionador
de tráfego apropriado. Se for usado o DS codepoint, o classificador é chamado (BA,
Behaviour Aggregate), se outros campos (número de porta, endereço IP, tipo de
protocolo) do cabeçalho são usados o classificador é chamado (MF, Multi-Field).
-
UERJ 2020 Redes de Comunicações 2 Pg. 209
Cap. 5 – QoS e Multimídia
A atribuição de PHBs a pacotes IP requer um contrato entre domínios.
A natureza exata da manipulação do pacote será baseada em uma política e o Service
Level Specification (SLS), que forma parte de um Service Level Agreement (SLA) entre
o usuário e o provedor. A política pode ser aplicada a todo tráfego de um único usuário
(ou um grupo usuário) e pode ser estabelecido quando for pedida a subscrição ao
serviço, ou pode ser aplicada em uma base de perfil configurável. A política
implementada pelo SLA pode incluir outras questões que não QoS, por exemplo,
segurança, restrições de tempo do dia, etc.
Um SLA inclui indicativos de quais PHBs estão disponíveis; onde codepoints
são atribuídos; regras de condicionamento de tráfego denominadas Acordo de
Condicionamento de Trafego (Traffic Conditioning Agreement - TCA); ações a serem
tomadas para o tráfego não conforme, dentre outras informações.
Um domínio DS contém nós DS de borda e nós DS interior, atuando os nós de
borda como condicionadores de tráfego. Estes nós implementam a parte TCA (Traffic
Conditioning Agreement) de um SLA.
-
UERJ 2020 Redes de Comunicações 2 Pg. 210
Cap. 5 – QoS e Multimídia
Outra parte do SLA é a definição de um perfil de tráfego para um fluxo de
pacotes. Quando pacotes de um fluxo de usuário excedem o perfil negociado de tráfego
se diz que eles estão out-of-profile, caso contrário, in-profile.
Após passar no classificador a informação sobre o pacote é passada para um
medidor que providencia informação de controle (se ou não o pacote está in-profile,
etc) para outras partes do condicionador. A seguir, os pacotes sofrem no condicionador
as funções de marcação e policiamento:
• marcador: pode trocar o DS codepoint do pacote – remarca o pacote
• moldador: retarda pacotes para impor in-profile ao fluxo
• descartador: descarta pacotes out-of-profile (impõe in-profile ao fluxo). Pode
ser implementado com o moldador com buffer de zero pacotes. Nós DS
interior podem executar condicionamento limitado de tráfego BA, mas a intenção é que
a função de condicionamento seja feita na borda do domínio (ou próximo dela).
O PHB Assured Forwarding (AF) permite a um domínio DS oferecer
diferentes níveis de certeza para encaminhamento de pacotes IP. Atualmente são
definidas 4 classes AF com 3 níveis de precedência para descarte em cada uma.Uma
marcação de classe AF é indicada por AFcd onde c é classe AF e d é a precedência de
descarte dentro daquela classe. Um exemplo de uso é que cada classe represente um
-
UERJ 2020 Redes de Comunicações 2 Pg. 211
Cap. 5 – QoS e Multimídia
nível de serviço mais alto (por exemplo, 1= platina, 2=ouro, 3=prata, 4=bronze), com
níveis de precedência baixo, médio e alto (1, 2, 3 respectivamente) para descarte em
cada classe. Assim, AF11 deveria ser a “melhor” marcação AF e AF43 a “pior”. A
implementação pode ser feita usando escalonamento/enfileiramento ponderado com
tráfego violadores sendo descartados ou remarcados para classes mais baixas, ou mais
alto nível de precedência de descarte ou ainda “melhor-esforço”.
O RFC2597 sugere o algoritmo RED (Random Early Drop) para controle de
congestionamento (via descarte de pacote, vide capítulo 1 de Redes 1).
O PHB Expedited Forwarding (EF) é usado para oferecer serviço de baixa
perda, baixo retardo e baixo jitter através de domínios DS. Se o serviço é fornecido, ele
se parece com aquele de uma linha arrendada virtual (VLL - virtual leased line) e é
conhecido como serviço premium. Este serviço poderá ser implementado com políticas
de escalonamento de filas baseadas em prioridades (PQ), round robin ponderado
(WRR), WFQ (Weighted Fair Queuing) e CBQ (Class-Based Queuing) (vide cap.1
-
UERJ 2020 Redes de Comunicações 2 Pg. 212
Cap. 5 – QoS e Multimídia
Redes 1!). Se uma fila de prioridade única é usada (a fila EF é sempre servida antes de
qualquer outro tráfego), então a implementação deve assegurar que outro tráfego não
fique bloqueado.
Breve comparação das filosofias para QoS:
A despeito das diferenças entre INTSERV e DIFFSERV, listadas no resumo
mostrado no slide 5-94, faz-se necessário alguns comentários.
O grande ganho com DIFFSERV é que a sinalização fim-a-fim e a manutenção
de soft-state por fluxo dentro do roteador, que é exigência de RSVP, não é mais
necessário aqui. Isto faz DIFFSERV mais fácil de desenvolver e mais escalável que
serviços INTSERV e RSVP. Por outro lado, não significa que serviços INTSERV e
DIFFSERV são mutuamente exclusivos, ao contrário, é provável que SLAs
DIFFSERV entre cliente e provedor possam ser estabelecidos para uso genérico, então
-
UERJ 2020 Redes de Comunicações 2 Pg. 213
Cap. 5 – QoS e Multimídia
reservas por fluxo baseadas em RSVP poderiam ser usadas para certas aplicações,
como, por exemplo, para uma conferência de vídeo importante dentro de uma
organização.
Todas técnicas provedoras de QoS que descrevemos até aqui (Serviços
Integrados/RSVP, Serviços Diferenciados e MPLS) são independentes da transação fim
a fim. Cada uma das tecnologias tomada isoladamente apresenta problemas para entrega
de QoS fim a fim para o grupo de difusão seletiva: Serviços Integrados têm problemas
de escalabilidade e Serviços Diferenciados têm problemas de garantias. No entanto,
parece sensato fazer interoperar Serviços Integrados com Serviços Diferenciados. O
benefício maior seria alcançado através da escalabilidade do uso do núcleo da rede
baseado em Serviços Diferenciados, usando-se sinalização RSVP para controle de
admissão baseado em recursos e/ou políticas, assistência na classificação e identificação
de tráfego, permitindo-se gerenciar a configuração dinâmica de roteadores. Certamente
esta é a combinação que explora as melhores características de ambas as tecnologias,
porém surgem dificuldades que deverão merecer soluções especiais.
Na prática, elas poderão ser integradas de modo a fornecer QoS fim a fim.
Mesmo não tendo sido padronizado até agora, uma visão de alto nível do melhor
-
UERJ 2020 Redes de Comunicações 2 Pg. 214
Cap. 5 – QoS e Multimídia
trabalho conjunto destes “pedaços” poderia ser como ilustrado no slide 5-95,
aproveitando o que há de melhor nas características de cada uma. Neste sentido, no
núcleo da rede, o tráfego fluiria pela aplicação da classe de serviço (poderia
alternativamente ser usado MPLS) e na borda de saída da rede, de novo se mapearia
para RSVP em direção ao destino. A vida real, no entanto, é diferente. Donos diferentes
de segmentos da Rede não facilita uma solução única otimizada. Então o mais sensato
até hoje é ter conhecimento em todas as diversas soluções. Analisaremos tendências
relevantes na última seção a seguir.
-
UERJ 2020 Redes de Comunicações 2 Pg. 215
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 216
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 217
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 218
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 219
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 220
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 221
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 222
Cap. 5 – QoS e Multimídia
-
UERJ 2020 Redes de Comunicações 2 Pg. 223
Cap. 5 – QoS e Multimídia
Neste capítulo estudamos diversas técnicas relevantes para a maioria das coisas
que se quer hoje e no futuro da Internet, todas associadas a garantias de QoS que não
eram exigidas anteriormente em correio eletrônico, navegação Web e downloads. Um
estudo seguinte deveria apontar para as questões de desempenho em redes que visem
multimídia, o que incluiria outras questões como as relacionadas ao servidor
multimídia, questões de compartilhamento de recursos e questões de transmissão de
dados. O material de apoio que indicamos (deSouzaeSilva.pdf) se dedica a isto.
Mostramos também algumas tendências quanto a infraestrutura de redes, e neste
sentido o material de apoio complementar é paul.comp-com-201101.pdf , precedido pela
leitura do pequeno texto em descricao-futuro-da-internet.pdf.