Dissertação de Mestrado

Teste de performance SCTP - rede 100Mbps com perdas

Cenário: COP como servidor, SOLDIER como cliente, Ethernet 100Mbps com perda de pacotes variável. Mensagens de 500 bytes.

Vazão em função da taxa de perda

Protocolo	0%	0,1%	1%	3%	10%
TCPM	90596	78846	57876	23396	878
SCTP	60773	56834	57030	46438	852

Perdas em %, vazões em kbps (1kbps = 1000 bits/s).

Em perdas moderadas (1% a 3%), o SCTP conseguiu manter uma vazão maior que TCP, possivelmente beneficiado pelo fato do teste remeter continuamente pacotes nas duas direções, o que permitiu ao mais elaborado SACK do SCTP atuar com presteza.

No teste de latência, a inexistência de tráfego contínuo nos dois sentidos impediu o SACK de atuar.

Latência em função da taxa de perda

Protocolo	0%	0,1%	1%	3%	10%
TCPM	281,0	483,9	5190,0	14418,5	67097,0
SCTP	318,5	1920,0	24662,0	82718,0	671100,5

Perdas em %, latência em µs

Dentre todos os testes, este foi o pior resultado do SCTP, por uma combinação de fatores:

RTO (timeout de transmissão) padrão igual a 1000ms, muito alto para uma rede local. Este parâmetro pode ser ajustado via sysctl;
RTO mínimo igual a 1000ms, também muito alto. Este parâmetro também pode ser ajustado. Este valor é o menor RTO praticado pelo controle de congestionamento, ainda que os cálculos baseados em dados reais apontem um RTO menor. Um RTO mínimo de 1 segundo é centenas de vezes maior que o ideal para uma rede local;
O TCP demonstrou possuir um RTO mínimo padrão bem menor, pois os testes demonstram que ele adaptou-se à rede com perdas;
O controle de congestionamento do SCTP segue exatamente o algoritmo "clássico", que recomenda entre outras coisas um RTO mínimo de 1 segundo. O TCP talvez já tenha incorporado outras heurísticas;
O controle de congestionamento poderia estar interpretando (erroneamente) que toda perda é causada por congestionamento, diminuindo cada vez mais sua vazão até estolar, enquanto o TCP estaria adaptando-se de alguma forma à perda fixa de pacotes.

No primeiro teste, que forneceu os dados para a dissertação e para o gráfico acima, ajustar o RTO mínimo padrão não ajudou muito: o tráfego começava rápido mas acabava estolando e convergindo para uma taxa muito baixa.

Num segundo teste, feito depois da dissertação concluída, o ajuste do RTO mínimo resolveu o problema, e o SCTP apresentou performance semelhante ao TCPM em redes com perdas. Isto enfraquece a hipótese do controle de congestionamento do TCP ser mais avançado que o do SCTP.

Assim, permanece ainda a dúvida se o controle de congestionamento do SCTP tem alguma instabilidade (que mudaria seu comportamento "conforme a fase da lua") ou foi cometido algum erro à época do primeiro teste.

Se o controle de congestionamento do SCTP não tiver nenhum bug, ainda assim a implementação LK-SCTP deveria considerar baixar os parâmetros ajustáveis de RTO para patamares bem mais baixos, pois a maioria do usuários não tenta fazer qualquer tuning do sistema, e ao experimentar baixa performance do SCTP, colocará automaticamente a culpa no protocolo ou na implementação.