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
Top Related