Este capítulo apresenta resultados experimentais mostrando a operação do XTC e suas principais funcionalidades. 

\section{Implementação Prática}
\label{sec:experimentalImplementacao}

O XTC foi implementado na linguagem Python e executado na plataforma de testes da Figura~\ref{fig:testbed}.  Para demonstrar seu funcionamento,
foram realizados alguns experimentos. Nesses experimentos, pacotes
são enviados do Gerador de Tráfego (GT) para o Receptor de Tráfego (RT) a uma taxa de pacotes fixa utilizando o software gerador de tráfego Iperf~\cite{tirumala2004iperf}. Um roteador virtual executando no Encaminhador de Tráfego (ET) é responsável por 
encaminhar esses pacotes. O Controlador de Tráfego (CT) mede a vazão alcançada pelo roteador e desempenha o papel do bloco Controlador da Figura~\ref{fig:tcm}. O bloco 
Regulador Autoajustável está desativado nesse experimento para permitir a análise da eficácia do controlador PI no controle de vazão do Xen pelo ajuste do \textit{cap}.
Para medir a vazão alcançada, o CT coleta a saída do servidor Iperf relatada pelo RT. Na prática, a medida de vazão e a execução do XTC devem ser realizadas na máquina que possui os roteadores instanciados. Porém, a medição foi realizada fora dessa máquina para garantir que os resultados sejam independentes da máquina ET, que pode estar
sobrecarregada pela alta taxa encaminhada. Como Controlador, o CT calcula o \textit{cap} baseado na lei de controle da Equação~\ref{eq:piControlLaw}
e atua remotamente no \textit{cap} do roteador virtual. Vale notar que a lei de controle calcula o $\log_{10}(cap)$, ao invés de um valor absoluto de \textit{cap}, assim o
atuador deve calcular o inverso do $\log_{10}(cap)$. A complexidade desse cálculo é desprezível na plataforma de testes utilizada. O XTC é baseado em operações e cálculos simples, o que o permite controlar um grande número de roteadores virtuais.

Os experimentos consistem em enviar durante 100~segundos pacotes de 64 bytes de dados do GT para o RT a uma taxa de 100~kp/s, que corresponde a um fluxo de 51,2~Mb/s.
A máquina CT deve ajustar o \textit{cap} do roteador virtual para alcançar uma vazão desejada de 20~Mb/s. Esse valor de vazão foi escolhido para mostrar
o comportamento do mecanismo quando está distante do ponto de operação, mas não tão longe a ponto de causar um comportamento indesejável no sistema.
A primeira análise do mecanismo calcula a vazão
média alcançada e o Erro Médio Quadrático (RMSE - \textit{Root Mean Square Error}) em relação a essa média, como visto na Figura~\ref{fig:average_rmse}, para diferentes combinações de parâmetros
detalhadas mais à frente. Essas medidas
são calculadas utilizando os valores obtidos durante o intervalo de 20 a 100~s de cada rodada do Iperf. Esse intervalo foi escolhido para desconsiderar o comportamento
transiente do sistema antes dos 20~s. A vazão média indica que o XTC alcançou a vazão desejada de 20~Mb/s. 
O RMSE, por outro lado, quantifica o comportamento oscilatório do XTC mostrando o quanto os valores de vazão se desviaram da vazão média ao longo do tempo. Os valores
de tempo de assentamento e máximo \textit{overshoot} não foram calculados nesses experimentos devido à oscilação observada na saída do sistema.
  
\begin{figure}[ht]
\centering

%Gerado com o script generate_average_rmse.gnu
\subfigure[Medida da vazão média e do RMSE.]
{\label{fig:average_rmse}
\includegraphics[width=0.48\textwidth]{./graficos/average_rmse.eps}}
%Gerado com o script generate_controller_results.gnu
\subfigure[Vazão alcançada - Configuração PAZ.]
{\label{fig:practicalSolution}
\includegraphics[width=0.48\textwidth]{./graficos/paperPraticalSolution.eps}}

\caption{Experimentos com a implementação prática do XTC.}

\end{figure}

Nos experimentos são analisadas quatro diferentes configurações. A primeira, chamada de CF (\textit{Cap} Fixo), consiste em desligar o XTC e atribuir um \textit{cap} 
fixo de 14\% ao roteador virtual. Nesse valor de \textit{cap} espera-se uma vazão média perto de 20~Mb/s. Na prática, essa configuração não é recomendada pois é difícil
saber de antemão um valor fixo de \textit{cap} que conduz o sistema a uma vazão específica. Isso ocorre pois o comportamento do roteador pode variar 
com a dinâmica do tráfego, o que justifica o uso de controle realimentado. Os resultados dessa configuração, mostrados na Figura~\ref{fig:average_rmse},
foram utilizados apenas como referência para avaliar o desempenho do XTC. Esses resultados mostram um alto valor de RMSE, o que indica que a vazão oscila
quando é limitada utilizando o \textit{cap} do Xen, mesmo sem o XTC. Assim, o Controlador deve lidar com esse comportamento particular do ajuste de \textit{cap}. A configuração
PC (Parâmetros Calculados) utiliza o XTC com os parâmetros do Controlador ajustados com os valores $K_p=-3,4\times10^{-6}$ e $K_i=22,1\times10^{-6}$, calculados anteriormente.
Em todas as configurações do XTC a vazão é medida e o \textit{cap} é ajustado a cada 1~segundo. Os resultados mostram que a vazão média obtida é próxima da desejada, 
comprovando a eficácia do XTC. A configuração PC, porém, insere mais oscilação comparada com a CF. Para diminuir a oscilação, o parâmetro $K_i$ foi ajustado para
diminuir o efeito da integral do controlador Proporcional-Integral, que é parcialmente responsável pela oscilação. Os resultados desse ajuste são mostrados
na configuração PA (Parâmetros Ajustados) com $K_p=-3,4\times10^{-6}$ e $K_i=10,1\times10^{-6}$. Como visto na Figura~\ref{fig:average_rmse}, essa configuração
reduz o RMSE em relação à configuração PC. Finalmente, a configuração PAZ (Parâmetros Ajustados e Zona morta) utiliza os parâmetros da configuração PA e o conceito de zona morta para
reduzir a troca de mensagens entre o Controlador e o Encaminhador. Nesse experimento obtém-se uma redução de $29\pm2,4\%$ das mensagens de controle necessárias
ao ajuste de \textit{cap} em comparação com a configuração PA. A comparação entre os valores de RMSE das configurações PA e PAZ mostra que é possível reduzir o número 
de mensagens sem aumentar a oscilação. O comportamento do XTC é apresentado na Figura~\ref{fig:practicalSolution}. Essa figura mostra a vazão de referência
e vazão alcançada pelo 
roteador ao longo do tempo em uma rodada da configuração PAZ.

Os experimentos demonstram que o XTC alcança uma vazão próxima à desejada. Entretanto, a resposta do sistema oscila em torno do valor
desejado devido ao ajuste do \textit{cap}. Esse comportamento representa o compromisso em controlar a vazão através de ajuste de CPU na plataforma Xen. 
Apesar disso, foi mostrado que o XTC na configuração PAZ introduz oscilação desprezível em relação à configuração CF, na qual o XTC não é utlizado.

\section{Diferenciação de Tráfego}
\label{sec:diferenciacao}

Os experimentos dessa seção demonstram a capacidade do XTC em realizar diferenciação de tráfego entre os roteadores virtuais.
Para isso, o XTC
garante dinamicamente uma vazão maior para determinados roteadores, através do isolamento dos recursos de CPU utilizados pelos outros roteadores. 
Isso é importante para garantir isolamento entre os roteadores virtuais,
que não é garantido no Xen nativo. Na implementação padrão de rede no Xen, todos os pacotes 
enviados e recebidos pelos roteadores virtuais são encaminhados pelo Domínio 0 como visto na Seção~\ref{sec:tarefasRedeXen}.
Como mostrado em Fernandes \textit{et al.}~\cite{fernandes2010virtual}, o Domínio 0 consome muitos recursos de CPU ao realizar esse tipo de tarefa, e
mesmo reservando mais núcleos de CPU para o Domínio 0, o desempenho das tarefas de rede não melhora, pois são pouco paralelizáveis.
Portanto, pode ocorrer um gargalo no Domínio 0 devido à saturação de seus recursos de CPU, e assim a taxa de encaminhamento de uma rede influencia na taxa das outras.
Para analisar essa situação, é realizado um experimento na plataforma de testes, na qual o ET possui três roteadores virtuais (RV1, RV2 e RV3) encaminhando
pacotes do GT para o RT. Nesse experimento, o GT envia para o RT três fluxos de pacotes de 64 bytes a 51,2~Mb/s durante 100~s. Cada roteador virtual
é responsável por encaminhar um desses três fluxos. Os roteadores compartilham o mesmo núcleo de CPU, mas não há disputa de recursos. O Domínio 0, por sua vez,
possui dois núcleos de CPU reservados. Primeiramente, não há limitação de CPU dos roteadores pelo
\textit{cap} e a vazão média obtida é medida com base nos últimos 80~s de cada rodada. Essa configuração
está indicada como Sem XTC na Figura~\ref{fig:differentiation}.

%
%Gerado com o script generate_paralell_average.gnu
\begin{figure}
\centering
\includegraphics[width=0.48\textwidth]{./graficos/eXpErImEnTPaperWeightThreeVM.eps}
\caption{Diferenciação de tráfego.}
\label{fig:differentiation}
\end{figure}

Os resultados mostram que os roteadores virtuais não são capazes de encaminhar os pacotes a 51,2~Mb/s, devido à saturação de recursos de CPU no Domínio 0.
Consequentemente, a vazão máxima alcançada em um roteador virtual foi de 23~Mb/s. Além disso, o Xen não conseguiu dividir igualmente a vazão entre
as máquinas. Esse último problema de justiça, porém, será deixado como ponto de investigação futura visto que esse experimento visa
verificar apenas a capacidade de diferenciação de tráfego do XTC.
Para permitir, por exemplo, que o roteador RV1 encaminhe mais pacotes, a taxa de pacotes 
que os outros roteadores enviam para o Domínio 0 pode ser limitada. Assim, o RV1 encontra mais recursos livres para enviar pacotes para o Domínio 0, aumentando sua vazão.
Para isso, utiliza-se o XTC em cada roteador virtual e o último experimento envolvendo três roteadores é repetido. Para o RV1, o XTC possui os mesmos parâmetros
$K_p$ e $K_i$ utilizados na configuração PAZ da Seção~\ref{sec:experimentalImplementacao}, porém com vazão limitada em 30~Mb/s. Para RV2 e RV3, o XTC é configurado para limitar a vazão em
15~Mb/s. Como nessa taxa a distância do ponto de operação é grande em relação ao utilizado na Seção~\ref{sec:experimentalImplementacao}, foram calculados novos valores do modelo 
do Sistema Xen para esses dois roteadores. Nesse caso, o ponto de operação utilizado foi de 27~Mb/s, resultando em $a=0,00339$ e $b=34816$.
 A partir desses valores
foram calculados os parâmetros do Controlador, como explicado na Seção~\ref{sec:projetoControlador}, encontrando $K_p=-4,825\times10^{-6}$ e $K_i=18,530\times10^{-6}$.
Os resultados do
experimento são mostrados na Figura~\ref{fig:differentiation}, designados como Com XTC. A partir desses resultados é mostrado que é possível atribuir
prioridade a um roteador virtual utilizando o XTC. 
Nos experimentos, o XTC foi utilizado com a configuração padrão do Xen, na qual o Domínio 0 é o gargalo. Apesar disso, o XTC pode também ser 
utilizado quando não há esse tipo de gargalo, mas há disputa de recursos no núcleo de CPU compartilhado pelos roteadores. Essa situação pode ocorrer, por exemplo, 
na utilização de novas 
tecnologias de E/S~\cite{liu2006high}, nas quais as tarefas de rede dos roteadores não necessitam da ação do Domínio 0. Nesse caso, o XTC pode também limitar a vazão 
máxima permitida para um roteador virtual, liberando para os outros roteadores os recursos do núcleo de CPU compartilhado.

\section{Funcionalidades do XTC}
Nesta seção são discutidas duas funcionalidades do XTC. A primeira é a tolerância a distúrbios, que é uma característica típica de sistemas de controle realimentado.
O próximo experimento mostra uma vantagem em utilizar controle realimentado ao invés de soluções estáticas, como o uso de tabela com 
correspondência de valor de \textit{cap} e vazão alcançada para determinados tamanhos e taxas de pacotes. As soluções
estáticas podem levar a decisões erradas como consequência de uma carga variável no roteador virtual causada por processamento adicional de pacotes.
Para demonstrar esse problema, a mesma plataforma dos experimentos anteriores é utilizada com o ET abrigando apenas um roteador virtual. O GT gera um 
fluxo de pacotes de 64 bytes a uma taxa de 51,2~Mb/s durante 100~s e a vazão de referência é de 20~Mb/s. Primeiramente, não sáo induzidos distúrbios no sistema.
A Figura~\ref{fig:disturbance} mostra os resultados obtidos quando, da mesma forma que na Seção~\ref{sec:experimentalImplementacao}, utiliza-se o \textit{cap} de 14\% para 
limitar a vazão no valor desejado. Nessa figura também é mostrado o desempenho do XTC para a mesma tarefa. Esses dois tipos de controle são representados, respectivamente, no eixo~X pelos
rótulos Fixo e XTC. Os resultados mostram que, sem distúrbios no sistema, a solução estática possui mesmo desempenho que o XTC. Apesar disso, a solução
estática possui como desvantagem a necessidade de montar previamente uma base de conhecimento com um grande número de relações entre \textit{cap} e vazão. Finalmente, o experimento
anterior é repetido com a inserção de distúrbio no sistema. O distúrbio nesse teste consiste em um processo executado no roteador que consume 14\% dos recursos
de CPU. Como mostrado na Figura~\ref{fig:disturbance}, o XTC alcança a vazão desejada mesmo na presença do distúrbio. 
Por outro lado, o distúrbio afeta o desempenho do roteador virtual no caso Fixo devido à disputa de recursos de CPU entre os processos de distúrbio e de encaminhamento
de pacotes. Essa diferença ocorre pois o XTC mede periodicamente a vazão e tenta alterar o \textit{cap} atribuído caso não consiga alcançar a vazão de referência, já na 
solução estática esse \textit{cap} é fixo.
%
\begin{figure}
%Gerado com o script generate_eXpErImEnTPaperDisturbance.gnu 
\centering
\subfigure[Tolerância a distúrbios.]
{\label{fig:disturbance}
\includegraphics[width=0.48\textwidth]{./graficos/eXpErImEnTdisturbance.eps}}
%Gerado com o script eXpErImEnTComparissonAdaptive.gnu
\subfigure[Adaptação a mudanças no sistema.]
{\label{fig:adaptacao}
\includegraphics[width=0.48\textwidth]{./graficos/eXpErImEnTComparissonAdaptiveAverage.eps}}
\caption{Funcionalidades do XTC.}
\end{figure}


Outra funcionalidade do XTC é a capacidade de se adaptar a mudanças no sistema utilizando o bloco Regulador Autoajustável da Seção~\ref{sec:autoajustavel}.
O experimento da Seção~\ref{sec:experimentalImplementacao} é repetido, utilizando os mesmos parâmetros $K_p$ e $K_i$ da configuração PAZ dessa seção e no caso
do Regulador Autoajustável esses são os valores iniciais do Controlador. Primeiramente,
um fluxo de 51,2~Mb/s é gerado e a vazão de referência do XTC é de 20~Mb/s. Nesse cenário, é comparado o desempenho do XTC com e sem o Regulador Autoajustável. 
Os resultados são mostrados na Figura~\ref{fig:adaptacao} representados respectivamente pelos rótulos A\_20 e N\_20.
Como no caso da
Seção~\ref{sec:experimentalImplementacao}, os resultados mostram que o sistema sem o bloco de Regulador Autoajustável consegue atingir a vazão desejada pois a distância
desse valor de vazão em relação ao ponto de operação não causa comportamento indesejável no sistema. Utilizando o Regulador Autoajustável, 
a vazão de 20~Mb/s também é alcançada mas com oscilação maior do que no caso de parâmetros de controle estáticos, como pode ser visto pelo valor de RMSE. 
Esse mesmo experimento é realizado novamente mas com a vazão de referência ajustada em 15~Mb/s que possui uma distância maior do ponto de operação.
O resultado sem o Regulador Autoajustável pode ser visto na Figura~\ref{fig:adaptacao} representado pelo rótulo N\_15, no qual a vazão alcançada é
10 vezes menor que a desejada. Com o uso do Regulador Autoajustável,
porém, os parâmetros são recalculados automaticamente para adequar o controlador às novas características do sistema.  
A Figura~\ref{fig:adaptacao} mostra com o rótulo A\_15 o resultado utilizando controle adaptativo com o ajuste automático de $K_p$ e $K_i$. Como observado,
o sistema consegue atingir a vazão desejada de 15~Mb/s mesmo quando os parâmetros iniciais do controlador estão calculados para um ponto de operação distante do utilizado.
Com base nesses experimentos é demonstrada a capacidade do XTC em se adaptar a mudanças das características do sistema sem a necessidade do cálculo prévio dos parâmetros
para cada ponto de operação ou estado do sistema. Pode ser observado, entretanto, que o controle adaptativo possui maior oscilação quando os parâmetros do controlador
não precisam ser ajustados, como no caso do teste em 20~Mb/s, o que é aceitável pois se trata de um sistema não específico para um determinado ponto de operação.
Para exemplificar a operação do Regulador Autoajustável, a Figura~\ref{fig:calculoParametrosRegAuto} apresenta a evolução do cálculo dos parâmetros $a$ e $b$
pelo Regulador Autoajustável em uma das rodadas do experimento anterior para as configurações A\_15, A\_20 e também no caso Fixo, no qual o Regulador Autoajustável
se encontra desligado (configurações N\_15 e N\_20). O cálculo do parâmetro $a$, como mostra a Figura~\ref{fig:parametroA}, não se estabiliza durante os 100 segundos
de experimento. Assim, como investigação futura pretende-se avaliar o tempo de estabilização do Regulador Autoajustável e propor um mecanismo
que desligue o Regulador Autoajustável quando o sistema já possuir resposta satisfatória. Isso é importante para garantir o funcionamento
desse bloco em diferentes situações.
A Figura~\ref{fig:parametroB} mostra que o cálculo do
parâmetro B é mais estável e pouco difere entre as configurações. A estabilidade e velocidade da escolha dos parâmetros dependem do ajuste das constantes
$\alpha$ e $c$ da Equação~\ref{eq:gradientAlg}. 
Como esses parâmetros foram calculados empiricamente neste trabalho, é necessário como ponto futuro
a investigação do cálculo correto desses parâmetros. Assim, apesar da eficácia mostrada em o XTC se adaptar às características do sistema, é necessário
investigar mais detalhadamente os efeitos do Regulador Autoajustável.

\begin{figure}[ht]
\centering

%Gerado com o script generate_average_rmse.gnu
\subfigure[Parâmetro A.]
{\label{fig:parametroA}
\includegraphics[width=0.52\textwidth]{./graficos/parameterA.eps}}
%Gerado com o script generate_controller_results.gnu
\subfigure[Parâmetro B.]
{\label{fig:parametroB}
\includegraphics[width=0.52\textwidth]{./graficos/parameterB.eps}}

\caption{Cálculo dos parâmetros do modelo pelo Regulador Autoajustável.}

\label{fig:calculoParametrosRegAuto}
\end{figure}

\section{Implementação Final}
\label{sec:produtoFinal}

Após a validação do mecanismo por meio dos experimentos de avaliação da proposta, desenvolveu-se a versão final do XTC e de seus mecanismos auxiliares.
A principal diferença da versão final em relação à utilizada nos experimentos anteriores, é a forma de medir a vazão de cada roteador virtual.
Na avaliação experimental, o XTC media a vazão de um roteador virtual a partir de saídas produzidas pelo Iperf
na máquina receptora. Apesar de servir para a validação do XTC, essa forma de medir não seria adequada pois o tráfego encaminhado pelo roteador seria
um tráfego genérico real e não um fluxo produzido pelo Iperf. Além disso, a vazão deve ser medida na própria máquina que encaminha a fim
de possibilitar uma maior escalabilidade e independência do mecanismo em relação às máquinas que estão recebendo os fluxos encaminhados.
Para tal, a arquitetura da Figura~\ref{fig:arquiteturaXTC} foi desenvolvida e cada um dos seus elementos é descrito a seguir.
Todos os módulos foram implementados na linguagem Python.

\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{./figuras/arquiteturaXTC.eps}
\caption{Arquitetura do XTC.}
\label{fig:arquiteturaXTC}
\end{figure}

\begin{itemize}
\item \textbf{Servidor de Medidas}: Este módulo executa a partir do Domínio 0 da máquina física. Ele acessa as estatísticas de bytes recebidos
pelos \textit{back-ends} presentes no Domínio 0. Essas estatísticas indicam o tráfego que cada máquina virtual enviou para o Domínio 0. O Servidor 
de Medidas de vazão mede essas estatísticas de rede através da  leitura do arquivo do Linux \texttt{/proc/net/dev}. Cada linha desse arquivo corresponde
às estatísticas de rede das interfaces de redes físicas ou dos \textit{back-ends}. A partir da coleta das estatísticas a cada intervalo,
definido por padrão em 1 segundo, o servidor envia a vazão de cada \textit{back-end} usando um \textit{socket} TCP (\textit{Transmission Control Protocol}).
\item \textbf{Cliente de Medidas}: Este módulo é uma classe que periodicamente recebe a vazão de cada \textit{back-end} do Servidor de Medidas.
O Cliente de Medidas pode ser instanciado no Domínio 0 ou em alguma outra máquina de controle remota, utilizando um \textit{socket} TCP com o servidor.
Este módulo possui a correspondência entre cada \textit{back-end} e o respectivo roteador virtual (RV) associado a ele. Essa correspondência
pode ser alterada em tempo de execução através de métodos desta classe. Através dessas informações o Cliente de Medidas é capaz
de calcular a vazão de um RV somando a vazão de todos seus \textit{back-ends} associados. Assim, o Cliente de Medidas
informa a uma instância do XTC a vazão do RV que esse XTC controla. O funcionamento conjunto deste módulo com o Servidor de Medidas provê maior escalabilidade
para o XTC pois evita que cada instância do XTC precise medir a vazão do roteador controlado. Isso permite que em um ambiente com $n$ instâncias
do XTC, o arquivo \texttt{/proc/net/dev} necessite ser acessado apenas uma vez a cada intervalo ao invés de $n$ vezes.
\item \textbf{XTC}: Este módulo executa as principais rotinas de controle do XTC e deve ser instanciado para cada roteador virtual (RV) controlado.
A instância do XTC deve ser executada na mesma máquina do Cliente de Medidas. Cada instância do XTC recebe a vazão do RV correspondente 
e configura seu \textit{cap} através do cálculo de suas rotinas de controle. A configuração do \textit{cap} é realizada através da comunicação
entre a máquina com o XTC e o Domínio~0 utilizando primitivas da Libvirt~\cite{libvirt}. Essas primitivas permitem a configuração do parâmetro \textit{cap} de forma remota.
\end{itemize}

