Aplicabilidade e desempenho do protocolo de transporte SCTP (Stream Control Transmission Protocol) Aluno: Elvis Pfützenreuter Orientador: Prof. Luis Fernando Friedrich

Mas, para que outro protocolo de transporte? TCP: transmissão confiável de bytes UDP: transmissão não confiável de datagramas Transmissão confiável de mensagens atômicas? Modulação da confiabilidade? Vários canais ou fluxos por conexão? IP / IPv6 TCPUDP ??? Enlace

História do SCTP Comitê SIGTRAN foi encarregado de procurar um transporte para SS7 MDTP (Multinetwork Datagram Transmission Protocol): protocolo sobre UDP que atendia os requisitos do SIGTRAN Evoluiu até tornar-se o SCTP, que foi promovido a protocolo de transporte IP / IPv6 UDP MDTP IP / IPv6 UDP SCTP IP / IPv6 SCTP

Associações e fluxos (streams) Associação SCTP: análoga à conexão TCP Fluxos: canais unidirecionais para envio de mensagens (até por direção) Número de fluxos negociado na criação da associação Terminal Fluxos

Mensagens atômicas Transmitidas e recebidas de forma indivisível pelas aplicações Podem ser maiores que um datagrama (se a implementação permitir) Aplicação pode ignorar as fronteiras das mensagens A ordem de entrega das mensagens é respeitada apenas dentro de cada fluxo (evita HOL Blocking) Fluxos Msg #1Msg #2Msg #3Msg #4 Msg #1Msg #2Msg #3 perdida Msg #3 aguardam retransmissão msg #1

Confiabilidade parcial Mensagens fora de ordem ou urgentes Mensagens com prazo de validade E as mensagens não confirmadas? Extensão PR-SCTP (Partial Reliability SCTP): baseia-se no prazo de validade Todas podem conviver no mesmo fluxo Msg #1Msg #2 urgente Msg #3 perdida Aguarda retransmissã o #1 Entregue assim que chegar

Multicaminhos Computador multi-homed: ligado por dois ou mais caminhos a uma rede ou inter-rede TCP/IP Fail-over automático, pode ser assimétrico Balanceamento de carga (extensão RivuS) Redundância de rede barata na Internet, sem precisar ser um AS (Autonomous System) Terminal Inter-rede (e.g. Internet) Link 1 Link 2 Link 1 Link 2 Link 3

Outros detalhes do SCTP Abertura da associação sem estado meio-aberto, imune a ataques blind spoof e SYN flood Checksum de 32 bits (CRC32c) Controle de congestionamento igual a TCP Estruturas TLV ao invés de bitmaps e campos fixos API BSD Sockets: estilo TCP e estilo UDP TipoComprimentoValor Tipo (8b) Flags (8b)Valor - alinhado em 32 bitsComprimento (16b)

Objetivos deste trabalho Achar oportunidades de uso do SCTP em lugar de TCP e UDP, para protocolos de aplicação preexistentes Testes de desempenho bruto Testes de desempenho com protocolos e aplicações reais (HTTP, SMB, RTP) Oferecer exemplos de uso da API Sockets com SCTP (softwares novos ou adaptados) Feedback aos mantenedores

Aplicabilidade do SCTP Em lugar de TCP Mensagens indivisíveis Múltiplas conexões ou fluxos paralelos Segurança melhorada Multicaminhos Em lugar de UDP SCTP não possui *cast Multimídia em tempo real (onde TCP tem sido aplicado)

Desempenho SCTP x TCP Implementações utilizadas: SCTP e TCP presentes no kernel Linux padrão Validade dos testes Testes de latência e vazão, com todas as garantias TCPM e UNIXM: protocolos de aplicação para simples separação de mensagens em TCP e UNIX Byte 0xEE Mensagem útilbyte 0xFF Protocolo de aplicação TCPM IP / IPv6 TCP SCTP TCPM Testes aplicados nestes pontos

Loopback - vazão Variável: tamanho da mensagem TCP: desempenho muito superior a SCTP (9x a 4x) CRC-32c (não é o grande problema) Separação de mensagens Cópias memória-memória Trocas de contexto Comparação injusta Sobrecarga TLV TCPM: vazão semelhante a UNIXM e SCTP

Loopback – latência Variável: tamanho da mensagem Latência SCTP 2x maior que TCPM Serialização das diversas latências Biblioteca lksctp-tools não é culpada Latência reside no kernel

100Mbps Variável: tamanho da mensagem Vazão do SCTP abaixo de TCP e TCPM (até 10x para mensagem de 10 bytes) Chunk bundling imperfeito Diferença estreita conforme aumenta o tamanho da mensagem (1000 bytes em diante) Latência do SCTP 25% maior que TCPM (parcialmente mascarada pela rede) Próximos testes usam mensagens de 500 bytes

100Mbps, perda 0% a 10% Vazão do SCTP maior que TCPM para perdas >1% SACK do SCTP foi eficiente Latência do SCTP péssima para perdas >1% RTO mínimo e RTO inicial muito altos (1000ms) (podem ser mudados) Controle de congestionamento clássico Novo teste sugere que bastaria tuning Continua sob suspeita Verificar melhorias do TCP

10Mbps latência de 5ms a 300ms Vazão do SCTP 15% menor que TCPM Vazão de ambos cai, e a diferença estreita, conforme aumenta a latência de rede Causa: buffer de recepção não ajustado Latência TCPM essencialmente igual a SCTP (seguem o RTT)

10Mbps latência 5ms a 300ms perda 1% Vazão SCTP 27% menor que TCP Latência SCTP 2x maior que TCP Ambas as diferenças estreitam conforme aumenta a latência de rede Buffer de recepção não ajustado RTO mínimo padrão muito alto (já citado)

1Mbps latência 50ms Latência 50ms +/- 25ms correlação 50% Duplicação 1% Perdas variáveis no shaping 1Mbps Sem perdas constantes Vazão SCTP 8% menor Latência SCTP 9% maior RTO mínimo padrão SCTP muito alto Teste com perda constante 0,1%: não provoca mudança significativa

11Mbps wireless ad-hoc Dois segmentos de rede no caminho e Ethernet Vazão combinada real: 3Mbps Qualidade do sinal propositadamente ruim Vazão SCTP 25% menor Latência SCTP 22% maior

Dois clientes 100Mbps Clientes fortes contra servidor fraco Vazão: SCTP dividiu igualmente a vazão entre os 2 clientes e nas 2 direções TCP teve problemas, vazão combinada caiu Latência com 2 clientes Aumentou 30% em SCTP Aumentou 15% em TCPM Causa: servidor fraco e ocupado, sobrecarga SCTP inerentemente maior

Multicaminhos 10/11Mbps Teste de funcionamento e não de performance Caminho primário ligado/desligado a cada 10 segundos SCTP precisou de tuning para funcionar idealmente neste ambiente path_max_retrans baixado de 5 para 1

Conclusões até aqui Vazão e latência do SCTP inerentemente piores Busca da maior vazão possível sugere TCP Migração para SCTP apenas na presença de outras vantagens Colaboração do CRC-32c na latência RTO mínimo padrão, e inicial padrão, de 1000ms Controle de congestionamento intolerante a perdas constantes?

Testes com HTTP Softwares: thttpd e httperf Sugestão de adaptação do HTTP ao SCTP, com uso de um par de fluxos por arquivo Idéia derivada da adaptação do SSL ao SCTP Uso de diversos fluxos SCTP entrega maior performance Custos de abertura/fechamento HOL blocking Questões pendentes nas adaptações

Testes com SMB Softwares: Samba e smbclient Simples uso de SCTP em lugar de TCP sem nenhuma mudança no protocolo ou na implementação Expectativa de melhoria de performance Realidade: performance SCTP abaixo do TCP, congruente com os testes de vazão/latência Adaptação mais profunda seria necessária

Testes com RTP Software: POC versão Transporte de MP3 sobre UDP RFC 2250, RFC 3119, FEC Confiabilidade parcial SCTP Prazo de validade, sem ordem PRSCTP SCTP ampliou consideravelmente a resistência a problemas de rede sem aumentar a sobrecarga Confiabilidade parcial exige colaboração da aplicação para total aproveitamento

Outros testes publicados KANG & FIELDS (2003) Transferência usando vários fluxos para aumentar vazão total RAJAMANI et al. (2002) Implementação KAME/BSD HTTP Resultados em geral concordantes com este trabalho Também pode-se usar mensagens fora de ordem para aumentar a vazão Proposta de KANG & FIELDS não se aplica a protocolos de aplicação baseados em TCP

Conclusões SCTP entrega as promessas Muito próximo da qualidade necessária para uso generalizado Não é panacéia Nenhuma fratura exposta na versão do LK-SCTP testada Falhas detectadas podem ser resolvidas a curto/médio prazo Vantagens provadas em protocolos reais (HTTP, RTP)

T H E E N D