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

TCP UDP ???

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é 65.536 por direção)● Número de fluxos negociado na criação da

associação

Terminal 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 #3Msg #3

aguardam retransmissãomsg #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 urgenteMsg #3

perdidaAguarda retransmissã

o#1

Entregueassim 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

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”

Tipo Comprimento Valor

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 brutoTestes 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 2.6.9 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 útil byte 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)

•10Mbpslatência 5ms a 300msperda 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 ● 802.11 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 0.3.7● Transporte de MP3 sobre UDP● RFC 2250, RFC 3119, FEC● Confiabilidade parcial SCTP

● Prazo de validade, sem ordem● PR—SCTP

● 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