NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
27 de setembro de 2000 | volume 4, número 5

volta à página inicial de NewsGeneration

Nesta edição:

NewsGeneration:



O Protocolo RSVP e o Desempenho de Aplicações Multimídia - Parte 2

Ana Luísa Pereira Schmidt <>

Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
2. Detalhes do ambiente
2.1 Aplicação de vídeo
2.2 Organização do ambiente de testes
3. Resultado dos experimentos
3.1 Resultados da seqüência Discovery
3.2 Resultados da seqüência Tangram2
3.3 Resultados do filme Starwars
4. Conclusão
5. Sites relacionados
Referências bibliográficas

Resumo

Como continuação do artigo publicado no volume 4, número 3 deste boletim, o presente documento retorna à questão da obtenção da qualidade de serviço para aplicações de tempo real. Foram reunidos alguns resultados que comprovam a importância dos métodos de controle de QoS, realizados em seqüências de vídeo. A coordenação de todo o processo foi entregue ao protocolo RSVP (ReSerVation Protocol) [1,2,3], que, juntamente com módulos de controle de tráfego e de roteamento, compuseram o ambiente de testes.

^

1. Introdução

A rede Internet atualmente oferece um único tipo de serviço: a entrega de pacotes segundo o melhor esforço. Nesse serviço, nenhuma garantia é dada ao usuário final em termos de requisitos temporais (retardo ou a máxima variação garantida deste - jitter). Para compor um ambiente com QoS, foi necessário acrescentar ao modelo de comunicação novas atribuições a todos os elementos envolvidos, tais como metodologias de classificação e escalonamento de pacotes, além de mecanismos de controle de admissão. Uma das propostas para o gerenciamento desse novo ambiente inclui o protocolo RSVP, objeto de estudo da primeira parte deste artigo [4].

Nessa segunda parte, serão apresentados os resultados obtidos com uma série de experimentos. O objetivo dos testes foi averiguar a presença, ou não, de ganhos em parâmetros de desempenho de aplicações multimídia quando o ambiente de transmissão sofria congestionamento. Nestes testes, foram consideradas como aplicações, seqüências de vídeo com características diferentes. Recursos foram alocados baseados na taxa média e na taxa de pico das seqüências. O congestionamento foi produzido por um tráfego melhor esforço bastante alto para competir pelos recursos juntamente com as aplicações de vídeo.

Os resultados dos experimentos realizados mostraram que o ambiente estudado oferece uma qualidade diferenciada para as aplicações com requisitos de tempo real.

O documento está organizado da seguinte forma: na seção 2, reuniram-se os detalhes da aplicação desenvolvida e do ambiente organizado para a realização dos testes; na seção 3, os resultados obtidos e, por fim, a conclusão na seção 4.

^

2. Detalhes do ambiente

Serão vistos agora os detalhes pertinentes à aplicação de vídeo desenvolvida e ao ambiente de testes organizado.

^

2.1 Aplicação de vídeo

A fim de determinar o comportamento de alguns parâmetros de desempenho de aplicações submetidas ao ambiente controlado de comunicações, foi construído um programa capaz de  gerar tráfego de vídeo. Neste caso, o tráfego gerado pode ser captado por diversos pontos receptores, uma vez que a aplicação foi construída para ser multicast. O receptor de vídeo observa e registra a distribuição do jitter, sua média, a variância e perda de pacotes ao longo da recepção.

Como fonte de vídeo, utilizaram-se seqüências reais de filmes encontradas na Internet. As seqüências, codificadas em MPEG, são analisadas, extraindo-se todos os tamanhos dos quadros MPEG em bits. As informações, juntamente com o número de seqüência do quadro, são então colocadas em um arquivo que servirá de entrada para o transmissor de vídeo.

O receptor de vídeo processa tais informações, sendo responsável por monitorizar a ausência de algum número da seqüência, registrar os tempos de chegada de cada pacote e calcular o valor de jitter conforme a definição:

onde, t1 e t2 indicam o tempo de chegada do pacote anterior e o tempo de chegada do pacote atual respectivamente e Tg indica o intervalo de tempo de geração de pacotes no transmissor, possuindo um valor de acordo com a taxa de transmissão da seqüência, geralmente de 24 ou 30 quadros por segundo. Cada valor do jitter é armazenado em uma posição de um vetor. De posse de todos os valores armazenados, contabiliza-se a média (soma de todos os valores e divisão pelo número de elementos) e a variância do jitter. Mais detalhes em [5].

O cálculo da perda é a razão da diferença entre o número de pacotes enviados e número de pacotes recebidos sobre o número de pacotes enviados. Em relação à perda de pacotes, calcula-se também a proporção de pacotes perdidos e a função de probabilidade de massa (FPM) do número de pacotes consecutivos perdidos, ou seja, a probabilidade do número de pacotes perdidos ser igual a um valor x. Esta última medida sendo a FPM da variável aleatória que indica o número de pacotes perdidos entre duas chegadas. O motivo para o cálculo desta última medida é que, através dela, pode-se avaliar se as perdas ocorrem em rajadas ou não, o que não é possível de ser analisado com a fração de pacotes perdidos. Com estas duas medidas, é possível caracterizar, de forma bastante precisa, o processo de perdas na rede.

^

2.2 Organização do ambiente de testes

Todos os testes foram realizados no campus da UFRJ. Foi utilizada uma aplicação fonte localizada no laboratório LAM (Coppe/UFRJ) e as aplicações destino ficaram no laboratório LAND (NCE/UFRJ). Estes dois laboratórios estão interconectados através de um anel FDDI. O esquema encontra-se representado abaixo.

esquema-testes

Figura 1 - Representação do fluxo de pacotes

Os roteadores dos laboratórios foram configurados com o sistema operacional FreeBSD, conforme a Figura 1. Nesta arquitetura, o módulo que implementa o protocolo RSVP atua com outros quatro módulos: o de roteamento, o classificador, o escalonador e o de controle de admissão.

Para executar a função dos três últimos módulos, foi utilizado o pacote de software ALTQ[6,7]. O pacote ALTQ foi agregado ao núcleo do sistema operacional, permitindo o controle total da interface rede. Tradicionalmente, o módulo que faz o controle de saída implementa a disciplina FIFO. O pacote ALTQ foi especificado para dar suporte a uma variedade de disciplinas de atendimento a filas com componentes tais como: estratégias de escalonamento, mecanismos para descarte de pacotes e para gerência de buffers.

No escopo deste trabalho, foram utilizados dois escalonadores que se encontram implementados no ALTQ: CBQ[8] e WFQ. Apenas o escalonador CBQ possui interface com o módulo RSVP.

O escalonador CBQ é baseado na criação de classes que possuem uma hierarquia. Cada classe possui a sua própria fila para a qual é atribuída uma prioridade e uma parte da capacidade da banda. O escalonador determina o próximo pacote a ser servido a partir da prioridade e do estado das classes (sobrecarregada ou não). Classes com mesma prioridade são escalonadas segundo a disciplina Weighted Round Robin. Suponha que se tenham três classes definidas. Se todas as classes estiverem recebendo tráfego, aquela que exceder a capacidade reservada, terá seus pacotes descartados, caso o buffer esteja cheio. Se uma determinada classe parar de receber pacotes, a capacidade do canal que ficar ociosa, será dividida igualmente entre as duas outras classes.

O princípio de funcionamento da política de escalonamento WFQ é baseado na criação de filas por classe de serviço, onde as filas são servidas em round-robin. O tempo alocado a cada uma das filas é proporcional ao peso atribuído a ela.

O classificador de pacotes implementado no ALTQ, após o estabelecimento com sucesso de uma sessão RSVP, atribui uma classe ao fluxo da sessão (o que determina a fila de saída dos pacotes) baseado na qualidade de serviço recebida do módulo RSVP e nas informações recebidas do módulo de roteamento.

Uma implementação bastante simples do controle de admissão é encontrada no pacote ALTQ. Cada vez que uma nova sessão é requisitada pelo RSVP, é verificado se a banda disponível (banda total menos a banda alocada para as outras sessões) é suficiente para atender a nova demanda.

^

3. Resultado dos experimentos

Nessa seção, estão reunidos os resultados dos experimentos realizados com aplicações de vídeo usando o ambiente de reserva definido nas seções precedentes. Foi utilizada uma aplicação multicast para enviar pacotes a partir de uma máquina definida como a fonte e receber/analisar pacotes nas máquinas destino.

De forma a criar uma situação de tráfego bastante intenso, no roteador onde a reserva é efetuada, foi usada uma ferramenta para geração de tráfego desenvolvida no nosso grupo de pesquisa [9]. Com isso, o roteador que implementava políticas de controle de tráfego servia também a outras transmissões de alta vazão, concorrentes com o tráfego da aplicação de vídeo. O objetivo do uso de outras fontes foi justamente estressar os módulos de controle de tráfego e observar seus desempenhos.

Através da interface com o RSVP, o CBQ recebe os parâmetros de QoS no estabelecimento da sessão. Desses parâmetros, o CBQ utiliza apenas o valor da taxa média pedida pela aplicação para a criação de classes dinâmicas que atendam ao pedido. Outros parâmetro passados (como taxa de pico, MTU) não são considerados. Outros parâmetros de configuração do CBQ, como prioridade, devem ser configurados de forma estática nos roteadores. Desta forma, o CBQ foi configurado com duas classes iniciais: a classe VÍDEO, onde foi alocada 20% da banda total (10 Mbps) e maior prioridade, e a classe DEFAULT, que possui o restante da banda, conforme mostrado na Figura 2.

Para comportar o tráfego de vídeo, o CBQ cria dinamicamente uma classe, herdando as mesmas características da classe VÍDEO, a partir do estabelecimento de uma sessão RSVP. A banda alocada é correspondente a QoS requisitada pela mensagem RSVP (no nosso caso específico, tal valor só poderá chegar a 2 Mbps).

Árvore de configuração CBQ

Figura 2 - Desenho esquemático das classes CBQ

O escalonador WFQ do ALTQ só possui um único parâmetro para ser configurado: a banda requisitada pela aplicação. Desta forma, o escalonador foi configurado, criando-se uma classe para o tráfego das seqüências de vídeo (onde a banda alocada corresponde a banda requisitada pela aplicação) e uma outra classe para o restante do tráfego.

Foram utilizadas três seqüências de vídeo com características diferentes nos testes. A primeira seqüência, chamada Discovery, tem taxa média de 1,4 Mbps, taxa de pico de 3,8 Mbps e uma duração de 30 s. A segunda seqüência, Tangram2, representa uma palestra que foi codificada em MPEG no nosso laboratório. A taxa média da seqüência é de 986 Kbs, a taxa de pico é de 3,4 Mbps e a duração é de 4,5 minutos. A terceira seqüência é o filme Starwars, sendo sua taxa média igual a 486 Kbps, a taxa de pico 5,5 Mbps e tendo duração de 85 minutos.

Foram realizados testes, para todas as seqüências, em um ambiente onde existiu o controle de QoS, e testes em um ambiente onde não foi implementado nenhum controle de tráfego. Apresenta-se, a seguir, os principais resultados obtidos nos experimentos.

^

3.1 Resultados da seqüência Discovery

Os seguintes experimentos foram realizados:

  1. Ambiente controlado com escalonamento CBQ, onde a banda requistada corresponde à taxa média da seqüência;
  2. Ambiente controlado com escalonamento WFQ, onde a banda requisitada corresponde à taxa média da seqüência;
  3. Ambiente controlado com escalonamento WFQ, onde a banda requisitada corresponde à taxa de pico da seqüência, e
  4. Ambiente sem controle.

Seq. Discovery - jitter sem controle

Figura 3 - Distribuição do jitter - ambiente sem controle

Seq. Discovery - WFQ taxa de pico

Figura 4 - Distribuição do jitter - WFQ com alocação pela taxa de pico

Nas Figuras 3 e 4, tem-se a distribuição do jitter no caso do ambiente sem controle e quando a política WFQ é usada e a alocação é feita pela taxa de pico, respectivamente. A partir dos gráficos, pode-se observar que, quando a alocação é feita pela taxa de pico, os valores de jitter são sempre inferiores a 0,02 ms. Já para o caso do ambiente sem controle, têm-se valores de jitter que são uma ordem de grandeza superiores aos do ambiente com controle.

Seq. Discovery - perda

Figura 5 - FPM do número de pacotes consecutivos perdidos

Um segundo parâmetro medido foi a função de probabilidade de massa (FPM) do número de pacotes consecutivos perdidos. Pode-se observar, na Figura 5, a FPM para o caso do ambiente sem controle. Através deste gráfico, vê-se que podem existir rajadas de perdas que variam de 3 a 13 pacotes com probabilidade da ordem de 10e-2. No nosso caso, foi usada a configuração do MPEG onde um quadro I é gerado após 11 quadros P e B. Como se tem perdas de até 14 pacotes consecutivos, certamente quadros I seriam perdidos, o que significaria uma qualidade ruim da aplicação destino.

No caso do CBQ e WFQ alocando pela taxa de pico, o número total de pacotes perdidos foi insignificante: 7, 2 e 0, respectivamente, não havendo perda de mais de 2 pacotes consecutivos. Com esse número de pacotes perdidos, certamente o usuário no destino teria uma boa qualidade para o vídeo sendo transmitido. A tabela abaixo apresenta um resumo dos resultados obtidos nos testes com a seqüência Discovery.

Parâmetro de QoS CBQ (1) WFQ (2) WFQ (3) S.C. (4)
Méd. jitter (ms) 2,178e-4 1,368e-4 -4,528e-5 1,956e-1
Var. jitter (ms) 6,450e-4 4,916e-4 8,199e-5 1,833e-2
perda (%) 0,77 0.22 0 46,67

Pode-se observar, através dos resultados da tabela, que a qualidade de serviço fornecida para a aplicação é bastante superior no caso do ambiente com controle. A média do jitter é diminuída em até 4 ordens de magnitude (WFQ com alocação pela taxa de pico) quando comparada com a média obtida para o ambiente onde nenhuma reserva é feita para a aplicação. Observando o percentual de perda, verifica-se uma queda acentuada, podendo-se chegar a uma taxa de perda igual a zero quando a alocação é feita pela taxa de pico.

^

3.2 Resultados da seqüência Tangram2

Os seguintes experimentos foram realizados com esta seqüência:

  1. Ambiente controlado com escalonamento CBQ, onde a banda requisitada corresponde à taxa média da seqüência;
  2. Ambiente controlado com escalonamento CBQ, onde a banda requisitada corresponde à taxa de pico da seqüência;
  3. Ambiente controlado com escalonamento WFQ, onde a banda requisitada corresponde à taxa média da seqüência;
  4. Ambiente controlado com escalonamento WFQ, onde a banda requisitada corresponde à taxa de pico da seqüência, e
  5. Ambiente sem controle.

Nos experimentos realizados para o ambiente sem controle, têm-se rajadas de perdas de 1 a 14 pacotes, como no caso da seqüência Discovery. Como foi usada a mesma configuração do MPEG, certamente quadros I seriam perdidos, o que tornaria a qualidade do vídeo no destino ruim. Quando se usa o CBQ com alocação de banda segundo a taxa média, têm-se perdas conscutivas de até 14 pacotes, não existindo melhora em relação ao ambiente sem controle. Já quando a reserva é feita pela taxa de pico, ainda se têm perdas acima de 3 pacotes, porém com probabilidade da ordem de 10e-3, o que reduz as chances de perdas de quadros I.

Para o caso da política WFQ, quando a alocação é feita pela taxa média, têm-se, no máximo, 4 pacotes consecutivos perdidos (com probabilidade da ordem de 10e-3), e, quando a alocação é feita pela taxa de pico, têm-se até 3 pacotes consecutivos perdidos (com probabilidade da ordem de 10e-3), o que representa uma melhora significativa em relação ao ambiente sem controle. As tabelas abaixo mostram um resumo dos experimentos.

QoS CBQ (1) CBQ (2) WFQ (3) WFQ (4) S.C. (5)
Méd. jitter 1,33e-2 5,30e-3 7,15e-3 3,39e-3 3,15e-2
Var. jitter 2,28e-3 3,73e-4 1,06e-3 1,68e-2 2,04e-3
% perda 29,0 13,7 17,0 9,24 48,6

Pode-se observar uma diminuição do jitter de uma ordem de grandeza quando o ambiente com controle é usado. O percentual de perda de pacotes também possui uma redução significativa. Como era esperado, observa-se que a QoS obtida, quando a reserva é feita usando a taxa de pico, é melhor do que quando a reserva é feita usando a taxa média.

^

3.3 Resultados do filme Starwars

São descritos, a seguir, os resultados de dois experimentos feitos com esta seqüência:

  1. Ambiente controlado com escalonamento CBQ, onde a banda requisitada corresponde à taxa de pico da seqüência, e
  2. Ambiente sem controle.

Através da distribuição do jitter, observa-se que o jitter apresenta valores superiores a 0,02 ms com probabilidade muito baixa com política CBQ. Já para o caso do ambiente sem controle, encontram-se valores de jitter até 0,16 ms. A FPM do número de pacotes consecutivos perdidos para o ambiente sem controle está apresentada na Figura 6. Nota-se que há perdas de até 30 pacotes consecutivos. Como observado anteriormente, isso aumenta as chances de perda de quadros I, significando uma qualidade ruim da aplicação no destino. No caso do ambiente com controle, tem-se uma perda igual a zero pacotes.

Filme Starwars - perda

Figura 6 - FPM do número de pacotes consecutivos perdidos

A tabela a seguir apresenta um resumo dos parâmetros medidos. Pode-se observar uma diminuição do jitter de três ordens de grandeza e o percentual de perda que atinge o valor zero quando é usado um ambiente controlado.

Par. de QoS CBQ (1) S. C. (2)
Méd. jitter (ms) 1,812e-6 9,771e-3
Var. jitter (ms) 2,017e-4 9,626e-4
Perda (%) 0 22,65

^

4. Conclusão

Neste trabalho, foi possível avaliar a QoS de aplicações de vídeo em presença de um ambiente onde o protocolo RSVP atua como gerenciador de recursos e onde são implementadas duas políticas de escalonamento: CBQ e WFQ.

Dois parâmetros de QoS foram avaliados: o jitter e a perda de pacotes. Para o jitter, foi calculada a sua distribuição, média e variância. No caso da perda de pacotes, obteve-se a FPM do número de pacotes consecutivos perdidos e a proporção de pacotes perdidos.

Três seqüências de vídeo com características diferentes foram consideradas. A primeira delas, Discovery, possui burstiness (taxa de pico/taxa média) igual a 2,7 e duração de 30 s; a segunda, Tangram2, tem burstiness igual a 3,4 e duração de 4,5 minutos; e a terceira, Starwars, possui burstiness igual a 11,7 e tem duração de 85 minutos.

Os resultados dos testes realizados com a seqüência Discovery mostraram uma melhora significativa do jitter e da perda de pacotes quando é usado o ambiente com controle. A média do jitter cai até 4 ordens de grandeza e a perda de pacotes pode chegar até zero. Através da FPM do número de pacotes consecutivos perdidos, verifica-se que não existem perdas de mais de 2 pacotes consecutivos quando o ambiente é controlado. O fato de se obter melhora significativa na QoS, qualquer que seja a alocação (média ou pico), pode ser conseqüência da curta duração da seqüência.

Para a seqüência Tangram2, observa-se que, quando a política CBQ é usada, não se obtém melhora significativa no número de pacotes consecutivos perdidos. Isso ocorre apesar de haver uma redução de até 35% na proporção de pacotes perdidos, o que mostra que somente este último parâmetro não é suficiente para avaliar a QoS da aplicação no destino. Já quando a política WFQ é usada, a partir da FPM do número de pacotes consecutivos perdidos, verifica-se que perdas de no máximo 3 (4) pacotes ocorrem com probabilidade da ordem de 10e-3 quando a alocação é feita pela taxa de pico (média).

No caso do filme Starwars só foram realizados experimentos com a política CBQ onde a alocação é feita usando a taxa de pico. Os resultados mostram melhora significativa no parâmetro jitter e na perda de pacotes. A partir da FPM do número de pacotes consecutivos perdidos, obtida para o ambiente sem controle, nota-se que tem-se perda de 5 a 30 pacotes consecutivos com probabilidade que varia de 10e-2 até 10e-5. Esta perda cai para zero quando o ambiente com controle é usado.

Analisando os resultados dos experimentos, observa-se que o jitter possui valores bem abaixo do mínimo definido em padrões internacionais para aplicações de vídeo [10], tanto para o ambiente sem controle, quanto para o ambiente controlado. Isto deve-se ao fato dos testes terem sido realizados dentro da rede da UFRJ, onde as aplicações passam por um número reduzido de roteadores. Contudo, o que é importante de ser observado é a redução de algumas ordens de grandeza na média do jitter quando o ambiente controlado é usado.

Em todos os experimentos onde foram usadas as duas políticas, CBQ e WFQ, pode-se notar que a política WFQ apresenta um desempenho superior à política CBQ em termos de QoS fornecida para a aplicação. Adicionando-se a esse resultado o fato da política WFQ possuir uma complexidade bastante inferior (no que diz respeito à configuração dos parâmetros e ao algoritmo implementado) à complexidade da política CBQ, isto torna a WFQ uma forte candidata a ser usada em um ambiente com serviços diferenciados.

Como possíveis extensões desse trabalho, pode-se citar a realização de testes dos diversos estilos de reserva em conjunto com um algoritmo para estimar a capacidade a ser reservada para os fluxos agregados (por exemplo, um algoritmo para cálculo de capacidade efetiva). Este último devendo ser incorporado ao módulo de controle de admissão.

^

5. Sites relacionados

IP QoS Page: http://qos.ittc.ukans.edu/

Class-Based Queueing (CBQ): http://www.aciri.org/floyd/cbq.html

ALTQ: http://www.csl.sony.co.jp/person/kjc/programs.html

Testes usando CBQ: http://corn.eos.nasa.gov/notebooks/ip-0007.html

Seqüências de vídeo podem ser encontradas em ftp://ftp.land.ufrj.br/pub/rsvp/seqs

^

Referências bibliográficas

[1] L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala, ``RSVP: New Resource ReSerVation Protocol'', IEEE Network, pp. 8-17, setembr 1993.

[2] B. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol - Version 1 Functional Specification, setembro 1997, http://www.isi.edu/div7/rsvp/rsvp.html

[3] J. Wroclawski, The use of RSVP with IETF Integrated Services, Internet-Draft, outubro 1996.

[4] Ana L. P. Schmidt, O Protocolo RSVP e o Desempenho de Aplicações Multimídia, Newsgeneration Volume 4, Número 3. http://www.rnp.br/newsgen/0005/rsvp.html

[5] Ana L. P. Schmidt. "Análise de Qualidade de Serviço para Aplicações de Tempo Real Utilizando Reserva de Recursos na Internet"', Tese de Mestrado, UFRJ, setembro 1999.

[6] K. Cho, ``A Framework for Alternate Queueing: Towards Traffic Management by PC-UNIX Based Routers'', Proceedings of USENIX 1998, Annual Conference New Orleans LA, June 1998.

[7] K. Cho, ALTQ - TIPS.txt, draft contido no pacote ALTQv.1.1.3.

[8] S.Floyd, V. Jacobson, ``Link-sharing and Resource Management Model for Packet Network'', IEEE/ACM Transactions on Networking, vol. 3 No. 4, agosto 1995.

[9] R. M. M. Leão, E. de Souza e Silva e S. C. de Lucena, ``A Set of Tools for Traffic Modelling, Analysis and Experimentation'', Proceedings of Tools' 2000 Schaumburg, IL, Março 2000.

[10] Raif O. Onvural. Asynchronous Transfer Mode Networks - Performance Issues. Artech House, 2 edition, 1995.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004