Quantos aos CODECs testados:

Quanto aos testes dos codecs realizados, conclui-se mais precisamente que:

• Com equipamento CISCO e o CODEC G.726, conseguiu-se o segundo melhor resultado com uma tolerância de 42,0% perdendo apenas para o equipamento HP-3800 usando o CODEC G.711 – 43,5%, apesar do CISCO ter apresentado em média melhor resultado com relação aos demais equipamentos, usando os quatros CODEC´s que foram analisados.

• Percebeu-se também que os CODECs G711 e G726 são mais tolerantes a perda de pacotes. O CODEC G729 vem em seguida com boa tolerância a perda. Por último, o G723 é o menos tolerante a perda de pacotes. Observou-se, também, que o roteador Cisco e o PABX Siemens apresentam maiores valores para tolerância a perda de pacotes.

5.9.2 - Quanto aos testes de compressão:

Perante os testes realizados sobre a compressão de cabeçalho concluiu-se que:

• Quando os experimentos foram realizados sem compressão ocupou-se 5,1% de banda consumida na rede e com compressão a percentagem cai para 1,95% de ocupação para apenas 1 fluxo de voz tanto para teste com cabeçalho comprimido e também para testes sem cabeçalho comprimido durante longos oito minutos, o que leva a conclusão de que com o cabeçalho comprimido conseguiu-se 38,5% de banda economizada, pois os pacotes não comprimidos os cabeçalhos tem um tamanho nominal de 66bytes e quando comprimido reduzem-se para 28bytes, somando simplesmente 14% de overhead se comparado com os mesmos testes em que não foi comprimido o cabeçalho resultando em 69% de overhead.

• Percebeu-se ainda que nos testes de compressão de cabeçalho, consumiu-se mais de 5.1% do link para um único fluxo de voz, para o mesmo experimento utilizando a compressão não se utilizou 1.95% do link, num segundo momento com testes realizados utilizando dois fluxos em paralelo sem compressão utilizou-se 10% da banda útil da rede quando poderia se colocar mais de cinco

fluxos de voz comprimidos em paralelo ou qualquer outro tipo de aplicação como vídeo, áudio ou dados, a banda que seria consumida por overhead utilizar- se-ia para informação útil otimizando o acesso em até 62%.

5.9.3 - Quanto aos testes de fragmentação com intercalação:

Com relação aos testes de fragmentação e intercalação de pacotes, apurou-se, em resumo, o seguinte:

• que, conforme se pode ler na Tabela 8 - a Fragmentação com e sem LFI e QoS, apresentou particulares vantagens do uso da técnica de intercalação de pacotes na medida em que para as mesmas quantidades de fluxos por tráfego - três fluxos (vide Tabela 8), e apesar de uma alta discrepância do tempo de processamento da simulação dos testes - 120seg * 10seg, os resultados foram melhores para os testes realizados com QoS e o LFI habilitado fim a fim. Alguns parâmetros de QoS testados conforme a tabela acima mostra que os resultados foram satisfatórios comparativamente com os resultados dos testes sem QoS e sem LFI habilitado apesar do tempo de teste ter sido doze vezes menor. Nesta mesma Tabela 8, tem-se discriminado a leitura dos parâmetros como o jitter, percentual de descartes de pacotes, banda consumida.

• que tendo em conta que a rede usada - Frame Relay, a LFI - depende de uma prévia configuração de QoS, independentemente das suas políticas de entrada e ou saída das interfaces dos roteadores levou a que haja um incumprimento de um dos parâmetros do FRTS como por exemplo o CIR (Taxa média de dados por unidade de tempo) o que fez com que a qualidade do sinal de fala fosse degradada, dado que valores muito acima do CIR tornou a rede instável.

• que outro valor como a taxa de pps (pacotes por segundos) bem como o tamanho de pacotes, ficou nitidamente evidenciado nos testes que devem sempre ser devidamente mensurados a fim de garantir QoS fim-a-fim;

• que ocorria perda de pacotes de forma indiscriminada, quando não se teve o cuidado de gerenciar adequadamente a banda, resultando em taxas de perda na

ordem de 58 %, mesmo para tráfegos classificados como sendo classes prioritárias, e, além disso, percebeu-se o elevado valor do delay tanto para valor mínimo como médio e o máximo delay registrado; jitter de 2,722 sec, contrariando as normas padronizadas;

• que sem a implementação de QoS, pacotes sofreriam perda indiscriminadamente, principalmente se os parâmetros FRTS não forem respeitados em algum momento e que com QoS preservou-se a integridade dos pacotes marcados como prioritários independentemente do tamanho dos demais fluxos que disputavam a banda em paralelo;

• que quando foi testado o nível de “saturação” / congestionamento do link percebeu-se que o congestionamento inviabilizou as aplicações independentemente das suas classificações e com a LFI habilitada e ou tendo ela desabilitada. O critério usado para testar congestionamento foi necessariamente a violação de alguns parâmetros do FRTS. Por outro lado, percebeu-se também que tráfegos com baixos valores e ou nos limites dos parâmetros de FRTS fluem normalmente;

• que usando Acterna e os dois ramais pacotes ftp acima da MTU relacionando os quadros de voz em um ambiente sem QoS, tornou impraticável a pratica de conversa telefônica e a não LFI provocou altos delay, atraso de serialização dos frames de voz na entrada da interface; altos jitter, causando perda e falhas na recepção da aplicação;

• que com a intercalação dos frames de voz - fluxos RTP, classe voz, marcação – EF, sempre receberam preferência na alocação de banda entre os demais frames da classe Business - marcação AF31 e obteve-se como resultados, baixos delay, jitter toleráveis, devido ao não atraso de serialização dos pacotes ftp e sem perda; Estes resultados apresentados nesta seção são incompletos, ou seja, não são resultados finais. São, portanto, os resultados pré-liminares que permitirão o bom entendimento dos resultados complementares, que serão apresentados no capitulo VI seguinte.

6 - CAPÍTULO VI: MEDIÇÕES COMPLEMENTARES COM TRÁFEGOS DE

DIFERENTES CODECS

“A teoria sempre acaba, mais cedo ou mais tarde,

assassinada pela experiência”

- Albert Einstein

Neste capitulo, estão relacionados todos os testes mais complexos, ou seja, nos testes ditos complementares são manipulados diversos parâmetros de melhoria de desempenho de redes. Esses testes foram levados a cabo, correlacionando diversas técnicas em um mesmo tráfego envolvendo, por exemplo, compressão de cabeçalho, LFI, QoS, alternando os codecs e repetindo os testes, por exemplo, sem compressão e sem a FLI, etc.

6.1 – Objetivo das medições correlacionando LFI, QoS, cRTP e CODECs em um

mesmo trafego.

Nesta seção é exibida uma série de resultados de medições onde são correlacionados parâmetros como QoS, LFI, cRTP e três tipos de codecs de voz diferentes, a fim de se avaliar o seguinte:

 O desempenho das aplicações e a sua viabilidade;

 Comportamento da rede, por exemplo, no quesito ocupação de banda;  Análise sobre a ocupação da banda por cada teste;

 Analise de viabilidade de codec;

 Optimização do enlace com compressão RTP;

 Quantidades de canais de voz a serem adicionados quando for comprimido RTP;  Perda de pacotes;

 Jitter, etc.

Neste sentido, são realizadas, pelo menos, quatro tipos de medições distintas e importantes com alternância do tipo de codec, tamanho de fragmento e habilitação ou desabilitação de compressão de cabeçalho RTP. Assim sendo, seguem os testes conforme descrito a seguir.

6.1.1 - Porquê estes testes

Estes testes têm como objetivo principal avaliar a viabilidade de aplicações VoIP em enlace de baixa capacidade, com o mínimo de banda reservada para aplicação VoIP em tráfegos paralelos, com aplicações do tipo dados. São, igualmente, manipulados pelo menos três parâmetros de melhoria de desempenho das aplicações e otimização de enlace:

 Três tipos de codecs distintos – G711, G729 e G726;  Implementação de QoS ou não implementação de QoS;

 Habilitação de compressão RTP ou a não habilitação da compressão RTP;  Habilitação da LFI ou a não habilitação da LFI.

6.1.2 - Metodologia de desenvolvimento dos testes

Para realizar os testes segundo a Seção 4.1.1 - "O que testar e quais testes fazer" do capitulo IV, da alínea (9) foi criada e seguida a metodologia baseada na caracterização de perfis de tráfegos para cada aplicação retratada nas matrizes correspondentes como o caso da matriz da Tabela 10 a seguir. Nessas matrizes serão correlacionados todos os parâmetros e políticas necessários para a realização dos referidos testes. São discriminados os tipos de filas bem como seus algoritmos de escalonamento, tamanhos de banda reservada, tipo de codec por teste, tamanho de payload, etc.

6.1.3 – Caracterização de perfil de tráfegos nas medições sem QoS, sem LFI, sem cRTP, com os Codecs g729,g726,g711.

A matriz (Tabela 10) relaciona as três classes de serviços de rede para a banda total de 512kbps, com as características do perfil de tráfego de cada aplicação e os respectivos protocolos da rede e utilizados. Percebe-se na Tabela 10 - que todos os tráfegos são tratados de igual forma na fila, não há habilitação da LFI, nem marcação de pacotes.

Desta forma analisa-se a caracterização do trafego de acordo com a Tabela 10 - a seguir:

Tabela 10 - Caracterização dos Perfis de QoS dos Tráfegos nos CPE´s (Sem políticas QoS, Sem cRTP, sem LFI, testados com Três codecs diferentes)

A Tabela 10 ilustra as três classes de serviços seguintes: voz, ftp e a default. Estas três classes receberam do total de banda de acesso frame Relay 512kbps, estando reservadas as seguintes quotas de bandas: Dados FTP = 400kbps, classe Default = 30kbps e Frames de voz = 60bkbps caso for usado codec de voz G729. Se, se usar outros codecs tal como o G711 a banda para classe voz seria de 82kbps, 52kbps ou 60kbps para o codec G726, pois, segundo dizem as recomendações, banda inferior comprometeria a viabilidade da aplicação de tempo real com voz interativa.

Na mesma Tabela 10 pode-se ainda perceber do número de pacotes por segundos gerados (nesse caso 50pps) a todas as aplicações; payload de cada aplicação; tempo de reprodução ou periodicidade de reprodução, bem como o tipo de transmissão, tipo de protocolo a ser usado por cada aplicação. Ainda ficou evidente o não uso da compressão, marcação de pacotes, algoritmo utilizado para implementar a fila, parâmetros de modelagem de trafego em Frame Relay como CIR,BE, entre outros parâmetros. Mostra também a tabela acima a quantidade de trafego por classe – 1 (um) tráfego de tempo real e 1 (um) tráfego FTP.

6.1.3.1 - Resultados dos testes e as suas respectivas interpretações

Como parte de resultados analisados, foi filtrado através do script do CEP03 cuja interface origem 192.168.0.10 a destino 192.168.0.6 de acesso ao Frame Relay os

30 últimos segundo de taxa de ocupação de banda, conforme a Tabela 40 - Ocupação da Banda da medição Sem QoS, Sem cRTP, sem LFI, codec G729 (Vide Apêndice I - Seção Acterna), permitindo montar a Tabela 11 a seguir.

Tabela 11 - Medição da banda Sem QoS, Sem cRTP, sem LFI, codec G729

O Roteador Cisco permite a coleta dos últimos 30 segundos dos tráfegos das aplicações. Com o VAD desabilitado o Roteador Cisco gera pacotes a taxa constante de 50pps (pacotes por segundos). Assim usando o codec G729, a ocupação de banda foi de 449600bits por segundos, ou seja, de 449kbps. Isso leva-nos a entender que esse valor em algum momento estourou o limite máximo de 400kbps de dados reservado. Entretanto, como havia uma reserva de 60 kbps de classe voz, esse valor ficou praticamente no limiar da banda reservada uma vez que os pacotes foram gerados durante 120sec a taxa de reprodução de 50pps e pacotes de 20bytes e 1000byes para voz e dados respectivamente.

Conclui-se, então, que as duas aplicações tiveram um consumo da banda em termos percentuais de 87,82% em relação a banda total (512kbps) e 97,74% em relação a banda reservada para as duas aplicações, pois essas aplicações não receberam tratamentos como a Compressão RTP.

Para se entender melhor a análise dos resultados extraídos com relação ao jitter para as aplicações de voz, Tabela 12 a seguir ilustra de fato como foi o comportamento das aplicações, analisando os seus respectivos valor de jitter.

A Tabela 12 a seguir de uma forma geral dá essa idéia da variação do jitter em termos de valores medianos para cada CODEC.

Tabela 12 - Valores de Jitter dos testes Sem políticas QoS, Sem cRTP, sem LFI, testados com Três codecs diferentes.

A Tabela 12 ainda diz-nos que o melhor valor mínimo de variação de atraso é de 15.40ms para um tráfego usando o codec G729, sendo que os outros dois valores estão no limiar – limite de 20ms e acima desse valor com jitter Maximo de 96,5ms essa variação é contra-indicado; entretanto para outros codecs estão valores acima de 15,40ms. Registrado jitter de 23,24 para tráfego usando o codec G726 . Entretanto, durante os testes, usando os ramais telefônicos pode perceber que foi inviável tal prática de telefonia, uma vez que a ligação era bastante perturbadora, com altos picos de interrupções e cortes.

Ainda de acordo com a Tabela 12, apesar do jitter de 15.40ms estar dentro do limite aconselhável, não foi um caso de sucesso durante os dois minutos (120sec) de conversa telefônica usando os ramais R3000 a R5000 ilustrados pela Figura 20 a seguir.

Figura 20- Medição Sem QoS e Sem LFI G729 e Sem cRTP .

Não houve fragmentação do pacote de dados nem compressão de cabeçalho. A ligação foi, entretanto, com picos de cortes, pois a variação de atraso fora imprevisível, chegando a 96,5ms e ora a 1,1ms, na havia qualquer linearidade entre essa variação do atraso.

A Figura 21 a seguir, segue as mesmas configurações ilustradas na Tabela 10, segue as mesmas descrições que a Figura 20, com algumas alterações no quesito tamanho do payload, variação do atraso, codec utilizado.

Figura 21 - Medição Sem QoS e Sem LFI G726 e Sem cRTP

Contrariamente, a Figura 20, foi usado o codec G726, que por conseqüência exige que o tamanho do payload seja de 80bytes, que somado ao cabeçalho passa para 126bytes sem a compressão.

Percebe-se ainda na Figura 21, que os valores de jitter foram superiores aos do mesmo teste usando o codec G729. Sendo assim, infere-se, com base nesses valores, que o codec G729 oferece mais aderência a frames de voz comparativamente com G726.

Fora perceptível que em um dado momento surgiu uma sequência de jitter de 20 -20-28,4-16.2-91,2-14. Isso implica dizer que além dos picos agudos nas ligações, essas sequências de variação de atrasos deixam a comunicação inviável, ou pelo menos, por alguns instantes de tempo os participantes não se entenderiam.

A Figura 22 - a seguir representa uma das ultimas series de três medições sem quaisquer políticas de QoS.

Figura 22 - Medição Sem QoS e Sem LFI G711 e Sem cRTP

A Figura 22, contrariamente as demais da serie, usa o codec G711, fazendo com que o payload do frame de voz seja de 206bytes sem a compressão RTP.

Contrariamente à Figura 21- anterior em que foi usado o codec G726, este foi usado o codec G711, que apesar de gerar frames com maior valor absoluto de payload, e jitter elevados muito similar os G726, este apresenta menos perturbações do que o G726 quando se escuta as conversações. Isso permite-nos concluir que o G711 possui melhor facilidade em lidar com o VoIP em relação ao G726, entretanto o G729 lidou melhor que os dois comparativamente, pois de uma forma geral o G729 permita maior compressão de áudio já codificado no codec.

O G729 reproduz a taxas mínimas de 8kbps e 10 frames por segundos, uma das qualidades que o diferencia das demais. Para se ter uma idéia gráfica das medições usando os três codecs diferentes, foi esboçado um gráfico de linhas que deixa

transparecer as oscilações dos fluxos em ondas continuas conforme representada no gráfico (Figura 23) a seguir.

Figura 23 - Gráfico de Jitter dos testes Sem políticas QoS, Sem cRTP, sem LFI, testados com Três codecs diferentes

Na Figura-23 percebe-se um gráfico - relação tempo de valores de jitter aceitáveis, vezes os valores de jitter gerados têm-se uma linha da cor rosa, que representa o limiar aceitável para boas aplicações de real time como voz de 20ms. Percebe-se que uma boa parte de tempo as aplicações mantiveram abaixo ou no limite ou pouco acima desse limite, seriam as aplicações de voz e os altos picos referem aos pacotes de dados.

Esses pacotes de dados, entretanto, não são afetados pelos altos valores de jitter, pois dados do tipo FTP não são sensíveis ao atraso ou suas variações – Jitter. Neste gráfico, percebe-se que a linha destacada a cor verde, tem uma forma mais linear possível se comparada com as outras duas linhas. Esta linha de cor Verde representa o fluxo de voz gerada pelo codec G729.

6.1.4 - Caracterização do perfil de tráfegos nas medições com LFI habilitado a 640bytes de fragmento, com QoS, com cRTP desabilitado e usando os codecs g711,g726,g729

A matriz Tabela 13 - a seguir segue as mesmas definições que a matriz – Tabela 10. Esta, entretanto, apresenta algumas particularidades, já que se trata de uma matriz de caracterização de perfil de tráfego para perfil de QoS em que ocorre a implementação

de LFI com fragmento de tamanho máximo de 640bytes; os pacotes são devidamente marcados e as filas receberão tratamento adequadas.

Tabela 13 - Caracterização dos Perfis de QoS dos Tráfegos nos CPE´s (Com políticas QoS, Sem cRTP, com LFI-640bytes, testados com Três codecs diferentes )

Percebe-se na tabela (Tabela 13) anterior que, ao contrário da outra implementação que não previa qualquer tipo de QoS esta prevê. Esta tabela prevê implementação de QoS, habilitação de LFI, porém, não prevê a compressão de cabeçalho. Deste modo, foram marcadas as classes serviços Voz e business para EF e AF31 respectivamente, e as mesmas receberam também as seguintes implementações das filas de QoS como Strict Priority e Fair Queue respectivamente, a classe default recebeu a fila FIFO.

Foram usados os seguintes codecs para cada um dos testes: G711, G726 e G729, entretanto, para fins de marcação de ocupação da banda, foi tomado como referencia o codec G729. Os resultados desses testes seguem na próxima seção.

6.1.4.1 - Resultados dos testes e as respectivas interpretações A Tabela 14 - a seguir ilustra o quanto de banda foi usado neste teste.

Tabela 14 - Banda ocupada na medição com QoS, Sem cRTP, com LFI-540bytes, G729 Na matriz (Tabela 14) pode ser percebido que apesar de não ter sido habilitada a compressão de cabeçalho, a ocupação de banda nos últimos 30 segundos a 50pps foi tecnicamente menor de 403,6kbps. Essa redução de consumo de banda está relacionada ao fato de que os fluxos receberam tratamento específico e fluíram com mais rapidez sem que um atrapalhasse o outro.

Comparativamente a Tabela 11 - resultado dos testes sem LFI, sem QoS e sem compressão usando igualmente o codec G729, esta com LFI, com QoS e também sem compressão apresenta uma vantagem de economia de banda na ordem de 449600bps para 403600bps o que representa em termos de percentagem um ganho de aproximadamente de 11%.

Conclui-se, portanto, que as duas aplicações voz e Dados (FTP), ocuparam 78,83% da banda total (512kbps) e 87,74% da banda reservada para as duas aplicações (460kbps).

Em termos de variação do atraso, foi contrariamente ao outro modelo, dentro os limites aceitáveis do 20ms, com apenas alguns picos, sendo assim a Tabela 15 - a seguir mostra essa variação de atraso em termos de valores medianos para cada codecs aplicando QoS e LFI.

Tabela 15 - Valores de Jitter de testes Com políticas QoS, Sem cRTP, com LFI-640bytes, testados com Três codecs diferentes

A Tabela 15 - mostra a relação da variação do tempo entre três tipos de codecs e as aplicações quando foram aplicados QoS, LFI e foram comprimidos os cabeçalhos. Se observados os valores medianos de todos os fluxos sem analisar a variação dos fluxos um a um, conclui-se que foi um caso ótimo, pois todos os valores de jitter estão abaixo do limiar recomendado.

Todos os codecs deram suporte adequado, entretanto o G729 continua sendo o melhor logo em seguida o G711 e na seqüência o G726 com diferenças mínimas se comparado ao G711. Na medição com QoS configurada e LFI habilitada sem compressão RTP usando o codec G729, o maior jitter para aplicação de voz foi de 5,9ms e o menor foi de 220microssec, e o maior jitter para aplicação de dados foi de 16,2 conforme a Figura 14 - a seguir.

Figura 24 - Medição Com QoS e Com LFI G729 e Sem cRTP

Com essas amostras fica claro que os serviços de tempo real não foram atrapalhados, pois intercalação dos frames de voz em pacotes de dados foi habilitada.