Dissertação de Mestrado
Dissertação de Mestrado
Cenário: COP como servidor, SOLDIER como cliente. Vazão da rede variada entre 200kbps e 300kbps, latência de 30ms, perdas variadas entre 0% e 10%.
Aplicativo adaptado para SCTP: poc versão 0.3.7.
Este teste determinou a capacidade do protocolo de entregar de forma razoável um conteúdo multimídia (mais especificamente, um áudio MP3 de 192kbps), através de uma rede com banda limitada e com perdas. É completamente diferente dos demais pois tem um grau de subjetividade, que é o ouvinte da música. Ainda assim, seguiu-se os seguintes critérios:
O teste também é diferente dos demais pois aqui comparou-se UDP versus SCTP; foi permitida em SCTP a entrega desordenada dos pacotes, bem como descarte por estouro de prazo de validade. Neste teste, a extensão PR-SCTP pôde finalmente ser usada e comparada com o SCTP padrão.
O jitter buffer no cliente de 200ms, exceto no protocolo FEC cujo buffer não pode ser configurado.
Apesar de apresentar bitrate fixo e recuperar-se de falhas, o formato MP3 não é apropriado para transmissão sobre canais não confiáveis. (Normalmente, RTP é usado sobre UDP, tornando-se assim um canal não confiável.) Assim, alguns protocolos foram desenhados para adaptar MP3 a RTP: RFC 2250 e RFC 3119 e FEC (Forward Error Correction), este último proposto pelo autor do aplicativo poc.
Nos gráficos abaixo, o eixo X é a perda de pacotes e o eixo Y é a banda passante da rede. Os pontos mais altos e mais à esquerda representam cenários de rede mais favoráveis (mais banda e/ou menos perdas). Há uma linha para cada protocolo (UDP, SCTP e PR-SCTP), que divide o gráfico em duas áreas:
Portanto, pode-se afirmar que, quanto maior a área à esquerda/acima da linha do protocolo, mais competente foi o protocolo em lidar com as dificuldades de rede.
A RFC 2250 é uma adaptação hipossuficiente para MP3 sobre RTP, pois ainda é muito sensível a perdas de pacotes, conforme mostra o péssimo desempenho do UDP no gráfico. Qualquer perda faz o conteúdo apresentar ruído periódico, e dificilmente se recupera disso.
Naturalmente, o uso de um protocolo confirmado melhorou muito a resistência a perdas. Usando-se SCTP, o RFC 2250 tornou-se viável em vários cenários com perdas. Outra característica interessante é que o áudio consegue recuperar-se após uma falha, cessando o ruído periódico após alguns segundos.
O PR-SCTP apresentou desempenho menos linear que o SCTP, e não funcionou com perdas acima de 2%. Possivelmente o padrão de descarte de pacotes do PR-SCTP, mais aleatório, não é compatível com o padrão RFC 2250.
A RFC 3119 é consideravelmente mais eficiente que a RFC 2250 se usada sobre redes com perda. E o uso de SCTP melhorou consideravelmente a resistência a perdas, conforme mostra o gráfico acima.
O PR-SCTP apresentou desempenho um pouco melhor que o SCTP padrão para perdas abaixo de 2%. O timeout das mensagens estava configurado para 200ms fixos. Acreditamos que, se a aplicação regular este valor dinamicamente de acordo com as condições da rede, o PR-SCTP poderia ter desempenho ainda melhor.
O algoritmo FEC Forward Error Correction faz uso código redundante para correção de erros. O conteúdo de 192kbps "engorda" para 260kbps, porém a grande redundância permite que o receptor recrie os dados de pacotes perdidos.
FEC é essencialmente o mecanismo utilizado em CDs de áudio, onde 25% dos dados são redundantes, o que permite corrigir erros causados por riscos e sujeiras. CDs de dados possuem dois níveis de redundância, cada um com 25%, o que torna-os ainda mais resistentes que CDs de áudio.
O FEC é talhado especificamente para redes com perdas como UDP, e o gráfico mostra que o desempenho sob UDP foi excelente. Note que, com poucas perdas, o áudio conseguiu passar mesmo quando a largura de banda da rede estava abaixo de 260kbps, o que mostra que o FEC realmente consegue reconstruir as perdas.
O SCTP padrão teve desempenho ruim, igual ou pior que UDP em todos os cenários. A principal razão é que ele não pode lidar com uma rede mais lenta que o fluxo de dados (260kbps). Isso é perfeitamente compreensível pois trata-se de um protocolo confirmado, que trabalha para transmitir todos os dados ao destino.
O PR-SCTP foi bem mais competente neste teste: conseguiu lidar com uma rede mais lenta que o fluxo (embora não tão bem quanto o UDP, pois o overhead do SCTP é maior). E o PR-SCTP foi melhor que UDP nos cenários com perda moderada ou severa de pacotes.
Este melhor desempenho do PR-SCTP não foi conseguido de graça. Foi necessário diminuir o prazo de validade das mensagens de 200ms para 80-100ms, ao menos com perda de pacotes igual ou maior que 5%. Sem este ajuste, o fluxo estola completamente.
O desempenho do PR-SCTP poderia ser ainda melhor se o transmissor calibrasse o prazo de validade das mensagens conforme a condição da rede, e o RTO mínimo fosse baixado para valores adequados à latência da rede (30ms). O ajuste manual para 80ms foi calculado pensando-se num RTT de 60ms (2x30ms), com uma pequena margem de variância, o que deixa espaço para apenas uma retransmissão. Numa rede com 10% de perdas, a chance de uma retransmissão diminui as perdas no receptor para 1% (10% de 10%), que por sua vez o FEC consegue tratar facilmente.