USAR-QoS: Simulador de Qualidade de Servi¸co para Apli-ca¸c˜oes In-

No intuito de avaliar o impacto da reatividade sobre uma aplica¸c˜ao Internet, bem como as novas pol´ıticas de QoS propostas neste trabalho, foi projetado o simulador USAR-QoS. A arquitetura do simulador se baseia em uma aplica¸c˜ao Internet real composta de um servidor provendo um certo servi¸co e um conjunto de clientes. O servidor cont´em uma ou mais filas e uma unidade de processamento com uma capacidade limitada de atendimento de requisi¸c˜oes. O comportamento do cliente ´e baseado na vers˜ao reativa do gerador de cargas httperf, apresentado no Cap´ıtulo 5.1.

O USAR-QoS foi implementado utilizando a ferramenta Simpack Toolkit que consiste de um ambiente de simula¸c˜ao desenvolvido em C++ [Fishwick, 1992]. Sua arquitetura ´e orientada a eventos e constru´ıda respeitando modularidade, de modo a permitir sua extens˜ao com novas pol´ıticas e recursos de QoS, como estrat´egias de controle de admiss˜ao e escalonamento.

A Figura 5.11 apresenta um diagrama de estados que representa o simulador USAR- QoS. Os eventos descritos s˜ao os seguintes:

de trabalho e as classes de pol´ıticas de QoS a serem utilizadas na execu¸c˜ao. Ao final da sua execu¸c˜ao o evento Sess Creation ´e escalonado para cada sess˜ao a ser criada e executada.

• Sess Create(): representa a cria¸c˜ao de uma nova sess˜ao. Para cada execu¸c˜ao escalona a seguir o evento Call Send Start.

• Call Send Start(): representa a submiss˜ao de um burst ao servidor. Para cada burst, este evento escalona a execu¸c˜ao dos eventos Sess Admission Control e Call TimeOut. • Sess Admission Control(): verifica se a sess˜ao corrente tem a permiss˜ao para ser aten- dida pelo servidor, de acordo com a pol´ıtica de controle de admiss˜ao de sess˜oes sendo executada. Caso a sess˜ao seja aceita, ´e escalonado o evento Burst Admission Control. Caso contr´ario a sess˜ao deve ser finalizada escalonando o evento Sess Destroy. • Burst Admission Control(): verifica se o burst corrente tem permiss˜ao para ser exe-

cutado pelo servidor de acordo com a pol´ıtica de controle de admiss˜ao de bursts. Se for aceito, o evento Server deve ser escalonado. Caso contr´ario, nada precisa ser feito j´a que o evento Call TimeOut ser´a executado posteriormente para aquele burst. • Server(): modela o servidor e suas filas de prioridade, onde a pol´ıtica de escalona-

mento ´e executada. Para cada burst ´e associada uma fila, de acordo com a pol´ıtica de escalonamento. Ao final da sua execu¸c˜ao o evento Call Send Stop ´e escalonado. • Call Send Stop(): finaliza a execu¸c˜ao de um burst, obtendo informa¸c˜oes sobre sua

execu¸c˜ao e escalona o evento Call Send Finalize.

• Call Send Finalize(): este evento ´e executado uma ´unica vez para cada burst, sendo escalonado pelo evento Call Send Stop ou pelo evento Call Timeout, de acordo com o comportamento do cliente. Esse mecanismo garante que cada burst ´e corretamente finalizado. Caso o burst executado seja o ´ultimo da sess˜ao e todos os outros bursts j´a tenham sido executados, este evento tamb´em ´e respons´avel por escalonar o evento

Sess Destroy. Caso ainda hajam bursts para serem executados na sess˜ao, ao finalizar sua execu¸c˜ao, escalona Call Send Start para que o pr´oximo burst seja executado. • Call Timeout(): controla o tempo limite de espera pela chegada da resposta ao burst

requisitado, de acordo com o comportamento reativo do cliente e o modelo de reati- vidade. Caso a resposta do burst correspondente n˜ao tenha sido recebida quando da sua execu¸c˜ao, o evento Call Send Finalize ´e executado com a finalidade de finalizar o burst corrente. Durante per´ıodos em que o desempenho do servidor piora, aumen- tando o tempo de resposta, este mecanismo simula o comportamento impaciente, engatilhando o evento Call Send Finalize antes que o Call Send Stop o fa¸ca.

• Sess Destroy(): executado quando uma sess˜ao deve ser destru´ıda. Finaliza a execu¸c˜ao do simulador quando todas as sess˜oes j´a foram executadas.

O simulador USAR-QoS foi preparado para registrar as seguintes informa¸c˜oes sobre cada execu¸c˜ao:

• Throughput de bursts respondidos: a taxa de bursts respondidos pelo servidor em cada instante de tempo.

• Throughput de bursts requisitados: a taxa em que os bursts s˜ao requisitados ao servidor pelos usu´arios em cada per´ıodo de tempo.

• Throughput de bursts expirados: a taxa de bursts em que o usu´ario requisita o pr´oximo antes de receber a resposta referente ao corrente, devido ao comportamento impaciente e a altos tempos de resposta. Isto acontece quando o evento Call Timeout engatilha a execu¸c˜ao do evento Call Send Finalize, de acordo com o descrito acima. • Throughput de bursts rejeitados: a taxa de bursts rejeitados pelo mecanismo de

controle de admiss˜ao de bursts a cada instante de tempo.

• Sess˜oes ativas: o n´umero de sess˜oes iniciadas e que n˜ao foram finalizadas, isto ´e, que tem bursts ativos ou que n˜ao tenham sidos submetidos a cada instante de tempo.

• Taxa de sess˜oes rejeitadas: a taxa com que o mecanismo de controle de admiss˜ao de sess˜oes rejeita sess˜oes a cada instante de tempo.

• Tempo de resposta: o tempo de resposta percebido pelo usu´ario, compreendendo o intervalo de tempo entre a requisi¸c˜ao do burst e o recebimento de sua resposta. • Tamanho da fila: o n´umero de bursts esperando servi¸co em uma das filas do servidor

a cada instante de tempo.

• Utiliza¸c˜ao do servidor: propor¸c˜ao de tempo em que o servidor est´a ocupado.

Os dados de throughput e tempo de resposta foram registrados, ainda, aplicando uma fun¸c˜ao de suaviza¸c˜ao chamada smooth bezier que reduz os picos e permite verificar melhor o comportamento das curvas.

Para realizar uma simula¸c˜ao utilizando o USAR-QoS, os seguintes parˆametros devem ser informados: taxa m´edia com que as sess˜oes ser˜ao criadas, n´umero total de sess˜oes a serem executadas, pol´ıtica de controle de admiss˜ao de sess˜oes, pol´ıtica de controle de admiss˜ao de bursts, pol´ıtica de escalonamento de requisi¸c˜oes, tipo de execu¸c˜ao (reativa ou n˜ao-reativa), e o arquivo de trace contendo as sess˜oes a serem executadas. ´E importante salientar que o servidor foi configurado com uma capacidade m´axima de 50 bursts por segundo.