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.


Recommended