UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO

Elvis Pftzenreuter

Aplicabilidade e desempenho do protocolo de transporte SCTP

Dissertao submetida Universidade Federal de Santa Catarina como parte dos requisitos para a obteno do grau de Mestre em Cincia da Computao

Prof. Luis Fernando Friedrich Orientador

Florianpolis, dezembro de 2004

Aplicabilidade e desempenho do protocolo de transporte SCTP

Elvis Pftzenreuter

Esta Dissertao foi julgada adequada para a obteno do ttulo de Mestre em Cincia da Computao Sistemas de Computao e aprovada em sua forma nal pelo Programa de Ps-Graduao em Cincia da Computao.

________________________________
Raul Sidnei Wazlawick Coordenador do Curso

Banca Examinadora

_________________________________
Luis Fernando Friedrich Orientador

_________________________________
Rmulo Silva de Oliveira

_________________________________
Mrio Antonio Ribeiro Dantas

_________________________________
Vitrio Bruno Mazzola

SUMRIO

Lista de siglas e abreviaturas Resumo 1 Introduo 1.1 1.2 1.3 1.4 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metodologia empregada . . . . . . . . . . . . . . . . . . . . . . . . . .

6 11 13 13 14 15 15 16 16 17 20 23 24 25 27 27 28 29 31 36 37 37 41 42

2 Histria do protocolo SCTP 2.1 2.2 2.3 2.4 2.5 2.6 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descrio geral da rede de sinalizao telefnica SS7 . . . . . . . . . . . Integrao entre redes SS7 e IP . . . . . . . . . . . . . . . . . . . . . . . A consagrao do SCTP como protocolo de transporte . . . . . . . . . . Outros protocolos de transporte em desenvolvimento . . . . . . . . . . . Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Apresentao do SCTP 3.1 3.2 3.3 3.4 3.5 Associaes e uxos (streams) . . . . . . . . . . . . . . . . . . . . . . . Mensagens indivisveis . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicaminhos (multi-homing) . . . . . . . . . . . . . . . . . . . . . . . Extenses propostas ao SCTP . . . . . . . . . . . . . . . . . . . . . . . Implementaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Aplicabilidade do SCTP 4.1 4.2 4.3 SCTP em substituio a TCP . . . . . . . . . . . . . . . . . . . . . . . . SCTP em substituio a UDP . . . . . . . . . . . . . . . . . . . . . . . . Novas possibilidades de uso do TCP/IP e da Internet . . . . . . . . . . .

2 5 Comparao de desempenho com TCP 5.1 5.2 5.3 5.4 5.5 5.6 5.7 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aplicativos construdos para o teste . . . . . . . . . . . . . . . . . . . . Sistema operacional e implementao do SCTP . . . . . . . . . . . . . . Ferramentas de simulao de rede . . . . . . . . . . . . . . . . . . . . . Computadores utilizados nos testes . . . . . . . . . . . . . . . . . . . . . Cenrios de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 5.7.6 5.7.7 5.7.8 5.7.9 Interface de loopback . . . . . . . . . . . . . . . . . . . . . . . . Rede 100Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . Rede 100Mbps com perda de pacotes . . . . . . . . . . . . . . . Rede 10Mbps com latncia . . . . . . . . . . . . . . . . . . . . . 10Mbps com latncia e perda de pacotes . . . . . . . . . . . . . . Rede 1Mbps, latncia e duplicao de pacotes . . . . . . . . . . . Rede 1Mbps, latncia, duplicao e perda de pacotes . . . . . . . Rede 11Mbps wireless . . . . . . . . . . . . . . . . . . . . . . . Dois clientes 100Mbps . . . . . . . . . . . . . . . . . . . . . . . 44 44 45 47 48 50 50 53 53 57 59 61 63 65 65 65 66 67 68 68 70 70 71 71 74 74 75 75 76 77 77 78 78 80 81

5.7.10 Multicaminhos 10Mbps e 11Mbps . . . . . . . . . . . . . . . . . 5.8 5.9 Validade dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Comparao de desempenho com TCP e UDP em aplicaes reais 6.1 6.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adaptao dos protocolos de aplicao ao SCTP . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.4 6.4.1 6.4.2 6.4.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outros aplicativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Aplicativos adaptados para os testes . . . . . . . . . . . . . . . . . . . .

Resultados

7 Concluses e trabalhos futuros ANEXO 1: Caractersticas de segurana do SCTP ANEXO 2: Detalhes de funcionamento do protocolo SCTP ANEXO 3: Extenses da interface BSD Sockets para suporte ao SCTP Referncias Bibliogrcas

86 89 97 104 116

Lista de Tabelas

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9

Vazo em kbps, conexes loopback . . . . . . . . . . . . . . . . . . . . . Latncia em s, conexes loopback . . . . . . . . . . . . . . . . . . . . Vazo e latncia em conexes loopback, em funo do nmero de uxos . Vazo em kbps, rede 100Mbps . . . . . . . . . . . . . . . . . . . . . . . Latncia em s, rede 100Mbps . . . . . . . . . . . . . . . . . . . . . . . Vazo (em kbps), rede 100Mbps com perda de pacotes . . . . . . . . . . Latncia em s, rede 100Mbps com perda de pacotes . . . . . . . . . . . Vazo em kbps, rede 10Mbps com latncia de rede . . . . . . . . . . . . Latncia de transao em s, rede 10Mbps com latncia de rede . . . . .

53 55 56 57 58 59 60 62 63 63

5.10 Vazo em kbps, rede 10Mbps com latncia de rede e perda de pacotes . . 5.11 Latncia de transao em s, rede 10Mbps com latncia de rede e perda de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.12 Vazo e latncia de transao, rede 1Mbps com de latncia de rede e duplicao de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.13 Vazo e latncia de transao, rede 1Mbps com latncia de rede, perda e duplicao de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.14 Vazo e latncia, rede 11Mbps wireless . . . . . . . . . . . . . . . . . . 5.15 Vazo e latncia, rede 100Mbps um servidor e dois clientes . . . . . . . 5.16 Vazo em kbps, conexes multicaminhos 10Mbps e 11Mbps . . . . . . . 5.17 Latncia em s, conexes multicaminhos 10Mbps e 11Mbps . . . . . . . 6.1 6.2 6.3 Vazo HTTP em Kbytes/s, rede de 100Mbps . . . . . . . . . . . . . . . . Vazo HTTP, rede de 1Mbps com perdas e latncia . . . . . . . . . . . . Vazo e latncia SMB (valores em segundos, vide seo 6.4.2) . . . . . .

64

65

65 66 66 67 67 79 80 81

Lista de Figuras

2.1 2.2 2.3 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9

Pilha de protocolos SS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . Pilha de protocolos com camada de adaptao M3UA . . . . . . . . . . . Pilhas de protocolos com camadas de adaptao M2UA e M2PA . . . . . Exemplo de script para simulao de rede com latncia e perda . . . . . . Vazo em conexes loopback . . . . . . . . . . . . . . . . . . . . . . . . Latncia em conexes loopback . . . . . . . . . . . . . . . . . . . . . . Vazo, rede 100Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . . Latncia, rede 100Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . Vazo em kbps, rede 100Mbps com perda de pacotes . . . . . . . . . . . Latncia, rede 100Mbps com perda de pacotes . . . . . . . . . . . . . . . Vazo em kbps, rede 10Mbps com latncia de rede . . . . . . . . . . . . Latncia de transao, rede 10Mbps com latncia de rede . . . . . . . . .

17 22 23 49 54 55 57 58 59 60 61 62 63

5.10 Vazo, rede 10Mbps com latncia de rede e perda de pacotes . . . . . . .

5.11 Latncia de transao, rede 10Mbps com latncia de rede e perda de pacotes 64 6.1 6.2 6.3 6.4 6.5 Vazo HTTP, rede de 100Mbps . . . . . . . . . . . . . . . . . . . . . . . Vazo HTTP, rede de 1Mbps com perdas e latncia . . . . . . . . . . . . Desempenho RFC 2250 sobre UDP, SCTP e PRSCTP . . . . . . . . . . Desempenho RFC 3119 sobre UDP, SCTP e PRSCTP . . . . . . . . . . Desempenho do protocolo FEC sobre UDP, SCTP e PRSCTP . . . . . . 78 79 82 83 84

Lista de siglas e abreviaturas

Ad-hoc: Em redes wireless 802.11, rede sem nenhum equipamento ativo (access point). ADSL: Asymetrical Digital Subscriber Line AH: Authentication Header. Vide IPSEC. API: Application Programming Interface. Conjunto de funes que um aplicativo deve usar para comunicar-se com uma biblioteca ou com o sistema operacional. AS: Autonomous System. Conjunto de redes tratado como um bloco nico e opaco pelo roteamento global da Internet. ATM: Asyncronous Transfer Mode. BGP: Border Gateway Protocol. Protocolo de roteamento dinnico utilizado entre ASs. Blind spoof: Tipo de ataque contra o protocolo de transporte TCP. BSD Unix: Sistema operacional compatvel com UNIX. BSD/Sockets: API do BSD Unix para acesso aos recursos de rede. CCS: Common Channel Signaling. Tecnologia onde o mesmo canal digital utilizado para contedo (voz) e dados de sinalizao. CIDR: Classless InterDomain Routing. Estabelece que redes topologicamente prximas tenham os mesmos prexos de endereamento. CIFS: Common Internet File System. Vide SMB. CODA: Sistema de arquivos distribudo que suporta desconexo temporria de rede entre cliente e servidor. CRC: Cyclic Redundancy Check. algoritmo de somatrio de vericao baseado em diviso de polinmios. CRC-32: verso de CRC que gera somatrio de 32 bits. CRC-32c: verso do CRC que gera somattio de 32 bits, com polinmio divisor diferente do CRC-32. DCCP: Datagram Congestion Control Protocol.

Denial-of-Service (DoS) atack: Ataque de negao de servio, que impede os usurios legtimos de usar determinado servio. DNS: Domain Name System. ECN: Explicit Congestion Notication. Noticao explcita de congestionamento, feita pelo roteador intermedirio atravs de um bit do cabealho de rede IP, e participada ao emissor atravs do protocolo de transporte. ESP: Encapsulating Security Payload. Vide IPSEC. FEC: Forward Error Correction. Algoritmo de somatrio de vericao que, transmitido junto com o dado original, permite detectar e corrigir erros no destinatrio. FDDI: Fiber Distributed Data Interface. FTP: File Transfer Protocol. Protocolo para transferncia de arquivos. H.323: Conjunto de protocolos para transmisso comprimida de voz e vdeo, usada por alguns sistemas de VoIP. Head-of-Line (HOL) Blocking: Problema em alguns protocolos conrmados que causa atraso na entrega dos dados. HTTP: HyperText Transfer Protocol. IANA: Internet Assigned Numbers Authority. ICMP: Internet Control Message Protocol. IETF: Internet Engineering Task Force. IPSEC: Internet Protocol SECurity. IP: Internet Protocol. Protocolo de rede da pilha TCP/IP. IPTables: Arquitetura de rewall do sistema operacional Linux, verso 2.4 em diante. IPv4: Internet Protocol version 4. IPv6: Internet Protocol version 4. ISDN: Integrated Services Digital Network. Padro de telefonia inteiramente digital. ISN: Initial Sequence Number. TSN inicial de uma conexo TCP ou associao SCTP. ITU: International Telecommunication Union.

ITU-T: International Telecommunication Union Telecommunication. Setor de padres da ITU. Kernel: Ncleo do sistema operacional. Kernel level: Cdigo que roda dentro do kernel. LDAP: Lightweight Directory Access Protocol. LSB: Least Signicant Bit. Bit mais direita de um nmero binrio. LK-SCTP: Linux Kernel SCTP. M2UA: MTP-2 User Adaptation. M2PA: MTP-2 Peer-to-Peer Adaptation. M3UA: MTP-3 User Adaptation. MDTP: Multi-Network Datagram Transport Protocol. MSB: Most Signicant Bit. Bit mais esquerda de um nmero binrio. MTU: Maximum Transmission Unit. MTP: Message Transfer Part. A subpilha inferior da pilha de rede SS7. Subdividida em MTP-1, MTP-2 e MTP-3. NAT: Network Address Translation. Netem: Disciplina de trfego de rede do sistema operacional Linux. NetBIOS: Network Basic Input/Output Services. Vide SMB. NFS: Network File System. NTP: Network Time Protocol. Octeto: Byte com invariavelmente 8 bits. OSI: Open Systems Interconnection. Pilha de protocolos de rede criada pela ITU-T. PMTU: Path Maximum Transmission Unit. POSIX: Portable Open System Interface for UNIX. Conjunto de padres que dene um sistema vulgarmente conhecido como UNIX-compatvel.

PR-SCTP: Partial Reliability SCTP. Extenso do SCTP que permite relaxar a conabilidade de mensagens. RFC: Request For Comment. RPC: Remote Procedure Call. RSVP: Resource reSerVation Protocol. RTP: Real Time Protocol. RTO: Retransmission TimeOut. Tempo que o transmissor espera para receber uma conrmao do receptor. Aps esse tempo, o pacote considerado perdido e retransmitido. RTCP: Real-time Control Protocol. RTT: Round-Trip Time. Tempo decorrido entre a transmisso do pacote e o recebimento da respectiva conrmao. essencialmente a soma das latncias de ida e de volta da rede. SCCP: Signaling Conection Control Part. Camada de aplicao da pilha SS7. SCTP: Stream Control Transmission Protocol. SFTP: Secure File Transfer Protocol. SG: Signaling Gateway. Equipamento que faz papel de gateway numa rede SS7. SIO: Service Information Octet. Em redes SS7, um sub-endereo dentro de um n da rede. Anlogo ao nmero de porta em TCP/IP. SIGTRAN: Comit Signaling Transport. SQL: Structured Query Language. SMB: Service Message Block. Protocolo de servio de arquivos e impressoras. SMS: Short Message System. Soquete: em BSD/Sockets, um manipulador de arquivo que corresponde a uma conexo de rede. Soquete UNIX: mtodo de comunicao interprocessos acessvel atravs da API BSD/Sockets. Spoof : Nome genrico dado a ataques que envolvem falseamento da origem, que mascara o invasor.

10

SS7: Signaling System #7. Pilha de rede de comutao de pacotes usada em telefonia. SSH: Secure Shell Protocol. SSL: Secure Sockets Layer. SSN: Stream Sequence Number. STL: Standard Template Library. STP: Signal Transfer Point. Equipamento que faz o papel de roteador numa rede SS7. SYN Flood: Ataque de negao de servio contra o protocolo TCP. TCB: Transmission Control Block. TCP: Transmission Control Protocol. TCP/IP: Transmission Control Protocol/Internet Protocol. Sigla pela qual a pilha de protocolos da Internet vulgarmente conhecida. TCPM: No contexto desta dissertao, protocolo de aplicao criado para testes de desempenho. Timestamp: Marca de tempo. TLS: vide SSL TLV: Type, Length and Value. Tipo de estrutura de dados de tamanho varivel. TSN: Transmission Sequence Number. UDP: User Datagram Protocol. UNIX: Famlia de sistemas operacionais. UNIX socket: vide soquete UNIX. UNIXM: No contexto desta dissertao, protocolo de aplicao criado para testes de desempenho. U-SCTP: Unreliable SCTP. WebDAV: Web Distributed Authoring and Versioning. Extenso do HTTP para manipulao de arquivos. VPN: Virtual Private Network. VoIP: Voice over IP. XML: eXtensible Markup Language. XTP: eXpress Transport Protocol.

RESUMO
Nas pilhas de protocolos de rede tpicas, como TCP/IP, a camada de rede oferece transmisso no convel de datagramas um servio muito primitivo para ser usado diretamente pelas aplicaes em geral. a camada de transporte a responsvel por oferecer servios de rede conveis e confortveis s aplicaes. A pilha TCP/IP oferece tradicionalmente apenas dois protocolos de transporte: TCP e UDP. O UDP implementa apenas o recurso de portas, sem acrescentar conabilidade rede. O TCP, por outro lado, oferece um servio convel, com conexes ponto-a-ponto e transmisso de bytes, abstraindo completamente as caractersticas da rede. TCP e UDP so dois extremos; algumas aplicaes desejariam usar ao mesmo tempo recursos de ambos os protocolos, e/ou ter controle mais direto sobre alguns aspectos da rede. Tal necessidade surgiu na sinalizao telefnica, o que motivou a criao de um novo transporte, o SCTP. O SCTP (Stream Control Transmission Protocol) guarda diversas semelhanas com o TCP, mas tambm apresenta diversos recursos adicionais interessantes: transmisso de mensagens indivisveis, multiplos uxos de mensagens por conexo, variao da conabilidade das mensagens, bem como melhorias de segurana. A proposta deste trabalho apresentar os recursos do SCTP, estudar a aplicabilidade do mesmo a protocolos de aplicao que hoje utilizam TCP ou UDP como transporte, e realizar testes de desempenho sobre uma implementao real do SCTP, com a simulao de diversas condies tpicas de rede. O desenvolvimento do trabalho envolveu uma razovel reviso bibliogrca sobre protocolos em todas as camadas, criao e adaptao de aplicativos para execuo dos testes, uso de ferramentas de simulao de rede, escolha de mtricas de avaliao de desempenho, e adaptao de protocolos de aplicao ao SCTP.

ABSTRACT
The network layer of typical network stacks e.g. TCP/IP offer best-effort, nonguaranteed datagram transmission service, too primitive for direct use by general applications. The transport layer is in charge of offering a reliable and comfortable network service for the applications. The TCP/IP stack traditionally offers only two transport protocols: TCP and UDP. UDP just implements port numbers and does not add any reliability to network service. In the other hand, TCP offers a reliable, point-to-point connection-oriented service for byte transmission, insulating completely the application from network characteristics. TCP and UDP offer two extremes of transport service; some applications would like to have resources of both protocols at the same time and/or have a more direct control over the network. Such needs arose in telephony signaling, which motivated the creation of a new transport protocol called SCTP. SCTP (Stream Control Transmission Protocol) is like TCP in many aspects, but also brings several new and interesting features: transmission of indivisible messages, multiple independent streams of messages per connection, options of partial reliability for some messages, as well as security improvements. This dissertation will present the new features of SCTP, study the applicability of SCTP for application protocols that use TCP or UDP as transport service today, and make performance tests upon a real SCTP implementation in several typical network scenarios. Dissertation development involved a reasonable bibliographic revision about protocols at all layers of a network, creation and adaptation of applications for testing, use of network simulation tools, selection of metrics for performance evaluation, and adaptation of application protocols to SCTP.

1. Introduo
1.1. Histrico A grande maioria dos sistemas distribudos fracamente acoplados, desde o mais trivial sistema cliente/servidor at os clusters Beowulf e MOSIX, fazem uso de TCP/IP como meio de comunicao de rede. A escolha recai sobre a pilha TCP/IP por ser universalmente suportada, e sem dvida por ser a pilha de protocolos em uso na Internet mundial. Um requisito no desenvolvimento de todo sistema distribudo fracamente acoplado a transmisso conrmada de mensagens indivisveis. No entanto, a quase totalidade das implementaes de TCP/IP oferece apenas transporte no conrmado de mensagens indivisveis (UDP), ou transporte conrmado de uma seqncia de octetos (TCP). Para adequar-se quilo que o TCP/IP oferece, cada protocolo de aplicao tem de implementar seu prprio mtodo de separao de mensagens sobre TCP; ou ento implementar controle de erros sobre UDP o que for menos inconveniente para a aplicao em questo. Conceber e otimizar um esquema de controle de erros sem dvida muito mais difcil. Assim, a maioria dos protocolos opta por usar TCP e implementar a separao de mensagens. Os protocolos clssicos da Internet que operam sobre TCP (SMTP, FTP, HTTP) utilizam linhas de texto legvel ASCII para conversao; o m-de-linha faz o papel de separador de mensagem. Existe uma tendncia moderna em usar-se XML sobre HTTP como mtodo de RPC. O uso de linhas de texto ineciente se comparado a estruturas binrias, mas facilita a separao de mensagens, o que explica em parte sua adoo generalizada. J nos protocolos que usam UDP como transporte, predomina o uso de estruturas binrias extremamente ecientes em tamanho e processamento. Exemplos: DNS, NFS, NTP. muito fcil tratar uma mensagem UDP, pois ela recebida exatamente como foi remetida. Tambm usam UDP os protocolos de multimdia em tempo real, pois nestes o controle de erros resume-se ao reordenamento no receptor. So usurios compulsrios de UDP as aplicaes que necessitam de broadcast ou multicast, pois a pilha TCP/IP suporta apenas difuso no conrmada, o que implica em usar transporte no conrmado. Mas a tendncia a diminuio do uso de UDP. Mesmo a multimdia em tempo real comercial tem migrado para TCP, embora este seja totalmente inadequado para a tarefa.

14 A migrao motivada no s pela diculdade em se usar UDP, mas tambm por motivos mais mundanos: TCP consegue furar mais facilmente o bloqueio de rewalls, proxies e roteadores NAT. Para car num exemplo: RealPlayer, uma das primeiras aplicaes para multimdia em tempo real na Internet, comeou usando UDP como transporte. Hoje, praticamente todas as streams Real so servidas sobre TCP. Ainda outro fator para o abandono do UDP a inexistncia de qualquer recurso de segurana contra seqestro de conexes. Uma aplicao UDP est por sua conta contra seqestro de conexes e forjamento de pacotes. O TCP menos frgil a esses ataques. O SCTP (Stream Control Transmission Protocol) um protocolo de transporte relativamente novo, que facilita a integrao de diversas tecnologias com TCP/IP e Internet. A principal caracterstica do SCTP a transmisso de mensagens indivisveis conrmadas. O foco inicial do SCTP foi a integrao das pilhas de rede SS7 e TCP/IP, na troca de mensagens de sinalizao telefnica. Sinalizao telefnica o uxo de informaes administrativas, como mensagens SMS, tarifao, servios ao usurio, sinal de ocupado etc, transmitida por uma rede de comutao de pacotes. A transmisso do contedo (voz) faz uso de uma rede de comutao de circuitos separada. Nessa funo criticamente importante, o SCTP j largamente utilizado, e cada vez mais na medida que as empresas telefnicas migram a rede de sinalizao inteiramente para TCP/IP. Mas o SCTP tambm tem potencial para ser usado fora do ambiente de telecomunicaes. Pode substituir com vantagens os protocolos clssicos de transporte (TCP e UDP) em boa parte dos protocolos de aplicao da Internet. Um estmulo adicional ao uso do SCTP a presena de caractersticas modernas de segurana. 1.2. Objetivo geral O objetivo geral deste trabalho apresentar o protocolo de transporte SCTP como uma alternativa vivel e consistente ao TCP e ao UDP na implementao de sistemas distribudos. O protocolo j existe como padro da Internet (RFC 2960) desde o ano 2000, e desempenha um papel vital em redes de telecomunicaes. Conforme ser explanado nos captulos a seguir, o SCTP resolve vrios problemas inerentes ao TCP, inclusive problemas de segurana. Ainda assim, sua existncia desconhecida por grande parte dos prossionais de informtica e mesmo do mundo acadmico.

15

1.3. Objetivos especcos Estudo da adaptabilidade de protocolos de aplicao existentes ao SCTP; Testes bsicos do acesso aos recursos do SCTP pela API BSD/Sockets; Criao de aplicativos bsicos baseados em SCTP para testes de vazo e latncia; Escolha de protocolos de aplicao e softwares a serem adaptados para o SCTP; Adaptao dos softwares ao SCTP e teste de funcionalidade bsica; Criao de cenrios tpicos de rede, pela variao de banda, latncia e perda de pacotes; Criao de ambiente multicaminhos, teste de funcionalidade e resistncia a falhas de rede; Testes de desempenho nos ambientes criados.

1.4. Metodologia empregada A metodologia empregada para chegar ao presente trabalho foi uma extensa pesquisa bibliogrca, sobre os seguintes tpicos:

o prprio protocolo SCTP; extenses propostas ao SCTP ainda em forma de drafts; as extenses API BSD/Sockets para suporte ao SCTP; a pilha de protocolos SS7, utilizada no sistema telefnico mundial; problemas de segurana do TCP e UDP; controle de congestionamento do TCP; camadas de adaptao entre SS7 e TCP/IP; algoritmos de checksum utilizados nos protocolos TCP/IP.

2. Histria do protocolo SCTP

2.1. Antecedentes Na pilha de protocolos OSI, a camada de transporte oferece servios de transferncia de dados em diversas modalidades: mensagens conveis, dados conveis (seqncia de octetos), dados no conveis, datagrama com reconhecimento, datagrama sem reconhecimento e pedido/resposta. So, no total, seis opes (MAZZOLA). J na pilha TCP/IP tradicional, h apenas os dois extremos: transporte conrmado de seqncia de octetos (TCP) e transporte no conrmado de datagramas (UDP). Para os servios orientados a conexo, o OSI oferece vrios nveis de conabilidade. Em linhas gerais, escolhe-se uma conabilidade inversamente proporcional oferecida pela camada de rede, para que a soma das duas resulte em conabilidade suciente, com o mnimo de sobrecarga. Essa caracterstica do OSI trai sua origem ele foi projetado por um comit de empresas de telecomunicaes. Em redes de telefonia, a conabilidade de cada meio de transmisso perfeitamente conhecida, geralmente muito alta e estvel ao longo do tempo, e faz sentido modular a garantia do servio de transporte. O protocolo TCP funciona mesmo que o meio subjacente seja pouco convel e instvel; porm no faculta aplicao relaxar nenhuma de suas garantias mesmo que o meio seja 100% convel. Em telefonia, conforme RUSSELL e ARIAS-RODRIGUEZ, muito comum a troca de mensagens atmicas entre sistemas; essencial um servio de datagrama conrmado, ou de mensagens atmicas conrmadas. Um servio de mensagem indivisvel conrmada sempre fez falta ao TCP/IP, muito embora essa lacuna seja surpreendentemente pouco lembrada na literatura de redes. Essa falta poderia ser suprida por uma camada de sesso, que se encarregaria de codicar e separar as mensagens individuais. Mas TCP/IP no dene formalmente uma camada de sesso; qualquer protocolo de sesso ou apresentao tem de ser implementado como uma subcamada inferior do protocolo de aplicao (STEVENS, 1994). o que acontece com o SSL Secure Sockets Layer que corresponderia s camadas de sesso e apresentao do OSI. Assim, na prtica, cada protocolo de aplicao TCP/IP tem de implementar seu prprio mecanismo de separao de mensagens.

17

Figura 2.1: Pilha de protocolos SS7

(a) Pilha de protocolos SS7

Fonte: RUSSELL

2.2. Descrio geral da rede de sinalizao telefnica SS7 SS7 (Signaling System #7) uma pilha de protocolos de comutao de pacotes, criada com a nalidade de transmitir mensagens de sinalizao telefnica. RUSSELL, CAMARILLO e ARIAS-RODRIGUEZ so as referncias bibliogrcas ao SS7 utilizadas neste trabalho. A pilha com os principais protocolos em cada camada mostrada na gura 2.1. O SS7 encarrega-se apenas de mensagens de dados, e no do contedo em si (voz ou imagem). O contedo transmitido por comutao de circuitos, para que a qualidade de servio seja garantida. (A tendncia usar comutao de pacotes com garantia de qualidade tambm para o contedo, por economicamente mais vantajoso.) Conforme RUSSELL, h uma distino bsica entre mensagens: as relacionadas a um circuito (e.g. relacionadas a uma ligao telefnica em andamento) e as norelacionadas.

18

As mensagens relacionadas no necessariamente trafegam pelo mesmo caminho que o contedo. Entre centrais telefnicas, as mensagens podem usar caminhos diferentes; j na ltima milha (ligao entre a central e o terminal telefnico) costuma existir um nico caminho eltrico. Em ISDN, um canal de 16kbps reservado para sinalizao. A pilha SS7, apesar de auto-suciente, pode delegar camadas baixas a outros protocolos (ARIAS-RODRIGUEZ). O ATM tem sido muito usado nessa funo pois tem, entre outros recursos, garantia de qualidade de servio. Mais recentemente, o TCP/IP comeou tambm a ser usado como meio de transporte para o SS7. As trs camadas mais baixas do SS7 tm funes semelhantes s das pilhas OSI e TCP/IP. Uma diferena importante em relao ao TCP/IP que as camadas de enlace e rede so responsveis, em seus respectivos contextos, pela retransmisso de pacotes perdidos. Em TCP/IP tal responsabilidade recai apenas sobre a camada de transporte. OSI permite responsabilizar tanto a rede quanto o transporte pela retransmisso. Em SS7, o estado dos enlaces redundantes informado s camadas superiores, que podem tomar decises baseadas nessa informao. Em TCP/IP, no existe forma simples de a aplicao obter essa informao. J a pilha OSI permite que uma conexo no nvel da camada de sesso faa uso de diversas conexes na camada de transporte (ou vice-versa), sobre as quais o aplicativo pode obter informaes, se quiser (MAZZOLA). Quando o SS7 utiliza outro protocolo como enlace ou rede, esse outro protocolo tem de oferecer as garantias supracitadas. O ATM as oferece nativamente. Para que o TCP/IP as oferea, necessrio um protocolo de transporte convel, como TCP ou SCTP. As redes SS7 concentram grande parte da inteligncia na prpria rede, o que alivia os terminais. Isso totalmente diferente da Internet, onde toda a inteligncia est concentrada nos terminais, e a rede apenas entrega pacotes individuais na base do melhor esforo, sem oferecer nenhuma garantia. ( bem verdade que haveria considervel inteligncia numa rede TCP/IP em que os roteadores implementassem RSVP e/ou IGMP. Mas ainda no esta a realidade da Internet atual.) A topologia de uma inter-rede SS7 bastante normatizada e hierarquizada. Os enlaces so classicados conforme o tipo e nivel hierrquico dos equipamentos interligados; o nmero mnimo e mximo de enlaces redundantes tambm normatizado. Graas a tudo isso, os algoritmos de roteamento dinmico, embutidos na pilha SS7, podem ser relativamente simples e muito ecientes na tarefa de prover o servio mais convel possvel. RUSSELL traz uma excelente explanao das regras da topologia SS7 bem como dos tipos de enlace. As redes de telefonia utilizam apenas transmisso convel de mensagens individuais. O SS7 prev transmisso de dados por seqncia de octetos, mas na prtica, at o presente momento, esse recurso no usado (RUSSELL).

19

O endereamento SS7 feito atravs de point codes, de tamanho mximo de 32 bits. Cada sistema nacional de telefonia usa um tamanho de sua escolha. Nos EUA, 24 bits. O point code internacional de 14 bits. O roteamento pode ser feito de duas maneiras: total ou parcial. Na forma total, cada point code tem uma rota especca, de forma anloga a uma rota esttica por destino IP, o que seria ineciente se fosse usado para todos os terminais. Na forma parcial, uma frao varivel do endereo usada como argumento de roteamento, de forma anloga ao roteamento por agregao IP. O nmero de point codes relativamente escasso, e o roteamento por agregao agrava essa escassez. Esse problema mitigado de duas formas. Primeiro, a prpria subpilha MTP possui um parmetro SIO (Service Indicator Octet) de 4 bits, que permite identicar de forma limitada servios diferentes dentro de um mesmo equipamento. Esse parmetro anlogo ao Protocol Field do cabealho IP; Segundo, a subcamada superior de rede SCCP implementa um endereamento suplementar, anlogo s portas dos protocolos de transporte TCP/IP. Numa rede tpica, um equipamento de central telefnica possui um point code e cada terminal telefnico conectado a ele possui um sub-endereo SCCP. Na rede SS7, os equipamentos denominados STP (Signal Transfer Point) fazem o papel de roteadores, e em algumas situaes atuam de forma anloga a roteadores NAT. Por exemplo, numa comunicao internacional, os point codes de cada pas precisam ser traduzidos de/para point codes internacionais. Em resumo, so as principais diferenas do SS7 em relao a pilhas como TCP/IP: presume uma camada fsica convel, ou um protocolo de transporte subjacente que oferea semelhante conabilidade; transporta de forma convel apenas mensagens individuais sem ordem intrnseca; no faz implementa transmisso de seqncia de octetos. Opcionalmente, permite agrupar mensagens em transaes para entrega ordenada; as mensagens nunca ultrapassam o tamanho dos datagramas. Tal limitao reete, por exemplo, no tamanho mximo de uma mensagem SMS celular. O servio de transporte um hbrido de datagrama conrmado (porque no fragmenta mensagens grandes) e mensagem indivisvel conrmada (porque permite entregar grupos de mensagens ordenadamente); suporta diretamente enlaces redundantes e notica as aplicaes das mudanas nos estados desses enlaces;

20

a topologia da rede fortemente normatizada, a funo de cada enlace bem denida, e os algoritmos de roteamento dinmico so parte integrante da pilha de protocolos; os componentes da rede tm inteligncia relativamente grande; a rede tende a ter parmetros estveis (performance, latncia, caminho percorrido entre dois pontos etc.); a troca de mensagens costuma ser entre equipamentos e no entre usurios (so os equipamentos, e no seres humanos, que provocam diretamente a comunicao).

2.3. Integrao entre redes SS7 e IP Embora a Internet (e implicitamente o TCP/IP) e a rede de telefonia SS7 sejam completamente diferentes, inclusive quanto a seus objetivos nais, existem motivos fortes para a busca da integrao:

acesso facilitado de uma a servios da outra; barateamento de alguns servios de telefonia atravs do uso de TCP/IP e/ou da Internet; integrao de dispositivos telefnicos xos e mveis Internet; alternativa de conectividade em reas onde no haja cobertura por uma das redes. Se toda comunicao de dados de telefonia feita atravs de mensagens indivisveis, requisito bsico achar um meio de transmitir tais mensagens atravs de uma rede TCP/IP. Conforme 2.1, o TCP/IP tradicional no apresenta protocolos de mensagem indivisvel conrmada. Coube ento a um comit formado em 1998, o Signaling Transport (SIGTRAN) escolher ou criar um protocolo para suprir essa falta. A primeira idia, segundo ARIAS-RODRIGUEZ, foi simplesmente adotar o TCP para o transporte de mensagens, por ser tradicional e bem conhecido, e tentar melhorar seus pontos fracos. No entanto, cedo reconheceu-se que o TCP era totalmente inadequado, pois delega aplicao toda a complexidade de separao de mensagens. Alm disso, o objetivo era escolher ou criar um protocolo de transporte que pudesse funcionar sobre ambos os protocolos de rede, TCP/IP e SS7 (e por conseqncia nos respectivos dispositivos), para o que o TCP denitivamente no adequado.

21 Embora o UDP em si fosse ainda mais inadequado, chegou-se concluso que um protocolo de aplicao operando sobre UDP seria o ideal. Embora ainda no existisse, o protocolo almejado foi denominado Common Transport Protocol CTP. Seus requisitos de design (ONG, 1999) eram:

Servir como transporte para os protocolos de mensagens de telefonia; Suportar extenses facilmente; Oferecer as garantias de um servio conrmado e suportar situaes adversas de rede como congestionamento; Ser resistente a falhas e permitir o uso de caminhos redundantes de rede, bem como noticar as aplicaes das mudanas de estado da rede; Segurana com alguma autenticao bsica das partes; Permitir alterao dos tempos de timeout e retransmisso pela aplicao; Multiplexar vrias instncias de aplicao em uma nica instncia de transporte, com garantia de ordenamento em cada instncia de aplicao; Permitir o transporte de mensagens maiores que o MTU do caminho.

Batizado o protocolo e descritos seus objetivos, o SIGTRAN passou a aceitar projetos. Algumas propostas apresentadas foram: UDP for TCAP (T/UDP), Simple SCCP Tunneling Protocol (SSTP) e PURDET. Outros protocolos j existentes tambm foram considerados: Service Specic Connection-Oriented Protocol (SCOP), da ITU-T, H.323 Anexo E, tambm da ITU-T, e o prprio Real Time Protocol o RTP atribui um timestamp a cada pacote, o que permite o reordenamento no destino. No entanto, o RTP no garante, por si s, a entrega. Entrementes, sem qualquer relao com o SIGTRAN, foi submetido ao IETF a proposta de um novo protocolo, denominado MDTP, por Randall R. Stewart e Qiaobing Xie. Seu principal objetivo era eliminar algumas fraquezas do TCP e suportar multicaminhos. O MDTP operava sobre UDP, portanto classicado como um protocolo de aplicao. Incidentalmente, o MDTP supria quase todos os requisitos do CTP. Tinha ainda uma grande vantagem adicional: os autores tinham desenvolvido uma implementao de prova de conceito, cujo desempenho era comparvel ao TCP. Eleito como CTP, o MDTP foi melhorado e estendido at resultar no SCTP atual.

22

Figura 2.2: Pilha de protocolos com camada de adaptao M3UA

ISUP/SCCP/TCAP (camadas superiores SS7) M3UA SCTP IP Protocolo de enlace

Fonte: SIDEBOTTOM et al.

O MDTP original nunca chegou a ser publicado como RFC. Muito embora o MDTP tenha servido de base ao SCTP, o nmero de revises foi grande e as modicaes foram profundas. de pouca valia estudar o MDTP para entender o SCTP atual, embora possa ser interessante do ponto de vista histrico (vide ARIAS-RODRIGUEZ para informaes sobre o MDTP e os passos evolutivos do SCTP). A integrao entre SS7 e TCP/IP faz uso um dispositivo denominado SG (Signaling Gateway) que intermedia as comunicaes entre terminais SS7 puros e terminais IP/SS7. Dependendo da modalidade de adaptao, o SG atua como roteador ou como gateway. Alm do SG, necessrio haver camadas de adaptao para os terminais IP/SS7, pois diversos elementos presentes em SCTP e TCP/IP (porta, endereo, associao) so diferentes ou inexistentes em SS7. A camada de adaptao inserida entre o SCTP e as camadas superiores SS7 implementadas pelo terminal. Uma camada de adaptao disponvel a M3UA (SIDEBOTTOM et al, 2002). A pilha TCP/IP mais o M3UA toma o lugar de todo o MTP, conforme mostra a gura 2.2. O M3UA possibilita ao SG repassar mensagens SS7 a um terminal IP/SS7. Porm, devido inexistncia da camada de rede SS7 (MTP-3), este terminal no possuir um endereo SS7 (point code) e no poder ser diretamente endereado por outros terminais SS7. O SG, nesse caso, faz papel de gateway. A camada M3UA serve para disponibilizar um servio TCP/IP rede SS7 da forma mais simples possvel, assumindo que a quase totalidade da rede de sinalizao ainda seja SS7 pura. Outras camadas de adaptao disponveis so M2UA (MORNEAULT et al, 2002) e M2PA (GEORGE), que em conjunto com TCP/IP substituem as camadas MTP-1 e MTP-2 mas mantm a camada MTP-3 do SS7. A gura 2.3 mostra as duas camadas de adaptao entre o SCTP e o MTP3. A camada de adaptao M2UA destina-se a terminais TCP/IP isolados, que possuem point-codes SS7. A camada MTP-3 ca diretamente sobre M2UA nos terminais,

23

Figura 2.3: Pilhas de protocolos com camadas de adaptao M2UA e M2PA

ISUP/SCCP/TCAP (camadas superiores SS7) MTP3 (SS7) M2UA SCTP IP Protocolo de enlace ISUP/SCCP/TCAP (camadas superiores SS7) MTP3 (SS7) M2PA SCTP IP Protocolo de enlace

Fonte: GEORGE et al. e MORNEAULT et al. (2002)

porm no nos SGs. Nestes ltimos, necessrio haver uma camada especial (NIF) de comunicao entre MTP2 e M2UA, que toma o lugar do MTP-3. Assim, o acesso da rede SS7 ao terminal TCP/IP tambm no completamente transparente com M2UA. A rede TCP/IP ainda tratada de forma discriminatria pelo resto da rede SS7, e o caminho para a rede TCP/IP passar por um SG bem determinado, diminuindo as possibilidades de redundncia e mesclagem. Ao menos o acesso aos servios SS7 bidirecional com M2UA, pois como foi dito o terminal TCP/IP possui um point code globalmente enderevel. A camada de adaptao M2PA oferece os servios necessrios para que a camada MTP-3 funcione diretamente sobre ela tanto nos terminais como nos SGs. Aqui o SG faz o papel de simples roteador, tal qual o STP numa rede SS7 pura. O terminal IP/SS7 possuir um point code globalmente enderevel como em M2UA. A camada M2PA permite a integrao total de SS7 e IP, bem como a construo de redes de sinalizao telefnica parcial ou totalmente baseadas em IP. 2.4. A consagrao do SCTP como protocolo de transporte Ao longo do trabalho de criao do SCTP, percebeu-se que este protocolo poderia ter aplicao fora do mbito da sinalizao telefnica. Muitas aplicaes poderiam usar o SCTP em substituio ao TCP. Assim como o MDTP, o SCTP tambm funcionava originalmente sobre UDP, e classicava-se como um protocolo de aplicao. A mudana mais radical no processo de evoluo do SCTP foi a migrao para a camada de transporte. O posicionamento do SCTP como um legtimo protocolo de transporte empresta respeitabilidade frente ao TCP, e abre caminho mxima performance possvel. Alm disso, o SCTP passa a ter seu prprio escopo de portas, o que evita a presena de servios conrmados no escopo de portas bem conhecidas UDP.

24 Essa deciso poderia atrasar o uso generalizado do SCTP, pois via de regra a camada de transporte implementa-se no kernel, e os usurios teriam de esperar os respectivos fornecedores de sistemas operacionais implementarem SCTP. J um protocolo de aplicao pode ser implementado como uma simples biblioteca. Se o SCTP fosse usado apenas para mensagens de telefonia, no haveria vantagem em migr-lo para a camada de transporte. A denio formal do protocolo est na RFC 2960 (STEWART et al, 2000). No entanto, esta RFC tem diversos erros e omisses. O SCTP Implementers Guide (STEWART et al., 2003c) contm a listagem das diversas correes que sero futuramente incorporadas RFC original. As capacidades do SCTP so facilmente aproveitveis por praticamente qualquer protocolo de aplicao que utilize TCP. Mas certo que a aplicao que adotar SCTP certamente ter de continuar suportando TCP durante um longo perodo de transio, para atender aos clientes de legado que ainda no implementam SCTP. Assim, decidiu-se que as portas TCP reservadas pelo IANA (as cognominadas portas bem conhecidas, e.g. porta 80 para Web) estariam tambm automaticamente reservadas para SCTP. O IANA livra-se de controlar um novo escopo de portas, e implicitamente permite o uso concorrente de TCP e SCTP para o mesmo servio no mesmo nmero de porta. H um recurso adicional de multiplexao de trfego no SCTP. Cada mensagem SCTP possui um rtulo ou identicador de 32 bits, informado pela aplicao. Isso permite que servios completamente diferentes faam uso de uma nica associao. (A associao SCTP anloga conexo TCP. A diferena de nomenclatura justica-se pelos novos recursos do SCTP.) O rtulo por mensagem um recurso primariamente voltado sinalizao telefnica, mas que pode ganhar importncia na Internet, na medida em que escasseiem as portas bem conhecidas TCP/SCTP. Ainda objeto de debate se os cdigos dos rtulos sero controlados de forma centralizada pelo IANA tal qual feito com as portas. 2.5. Outros protocolos de transporte em desenvolvimento O SCTP no cobre todas as lacunas deixadas entre o UDP e o TCP. Diversos outros protocolos tm sido propostos para aumentar o leque de recursos da camada de transporte do TCP/IP, dentre os quais citamos alguns que de alguma forma sobrepem total ou parcialmente as propostas do SCTP.

25

O protocolo XTP (eXpress Transfer Protocol) oferece praticamente todos os servios hoje oferecidos separadamente por TCP e UDP, e com diversas vantagens sobre o TCP e.g. menor sobrecarga e retransmisso mais gil de pacotes perdidos. Na ausncia do suporte ao XTP em um dos terminais, as pilhas de rede comutam automaticamente para TCP, de forma transparente s aplicaes. Neste ltimo ponto o XTP leva uma grande vantagem sobre o SCTP. Alm disso, o XTP oferece recursos inditos de multicast convel (recurso muito atraente para sistemas distribudos), e controle dos parmetros de qualidade de servio. Finalmente, o XTP no depende do protocolo de rede IP; ele pode ser adaptado diretamente a outros protocolos de rede ou mesmo diretamente sobre protocolos de enlace (e.g. ATM). Vide DANTAS e MENTAT para mais informaes sobre o XTP. DANTAS traz em seu livro diversos testes de desempenho do XTP versus TCP, inclusive com o uso de multicast convel para distribuio de arquivos. O protocolo DCCP (Datagram Congestion Control Protocol) bem menos ambicioso. Ele oferece apenas um servio ponto-a-ponto essencialmente igual a UDP (no convel), sem suporte a multicast, porm com controle de congestionamento. Vrios algoritmos de controle de congestionamento podem ser suportados; a aplicao escolhe o melhor conforme o tipo de trfego. FLOYD descreve tanto o protocolo DCCP quanto a motivao de sua criao. O protocolo NETBLT (NETwork Block Transfer Prototocol) tem como prinicipal objetivo a transferncia de grandes quantidades de dados, ou seja, proporcionar grande vazo, inclusive em redes de grande latncia. Por outro lado, o VMTP (Versatile Message Transfer Protocol) foi desenvolvido para transportar transaes no estilo RPC (em que a baixa latncia mais importante), e fornecer uma infra-estrutura de transporte voltada para sistemas distribudos, contando inclusive com servios de multicast (vide DANTAS para informaes sobre NETBLE e VMTP). 2.6. Concluses Embora o SCTP seja ainda pouco conhecido na comunidade de tecnologia da informao em geral, j um fato consumado em telecomunicaes, e aparece em praticamente toda literatura moderna dessa rea. Como foi visto, o SCTP uma pea indispensvel na integrao entre redes SS7 e IP. Em todo o mundo, essa integrao anda a passos largos, e as novas redes de sinalizao

26

telefnica tendem a ser parcial ou totalmente baseadas em IP, o que concorre inclusive para a reduo do preo dos servios de telefonia ao consumidor nal. O SCTP um protocolo novo, com caractersticas modernas, que absorveu as lies aprendidas nas ltimas dcadas com os demais protocolos de transporte da pilha TCP/IP. O comit SIGTRAN fez um excelente trabalho ao procurar no reinventar a roda no processo de criao do SCTP a partir do MDTP. Tambm foi feliz em tornar o SCTP adequado ao uso na Internet pblica, sem perder de vista o objetivo inicial do comit que era o suporte ao transporte de sinalizao telefnica.

3. Apresentao do SCTP
A RFC 2960 (STEWART et al, 2000) contm a descrio ocial do protocolo SCTP. A denio ali contida diz:

"O protocolo SCTP um protocolo de transporte convel operando no topo de uma rede de pacotes sem conexo como IP. Oferece os seguintes servios a seus usurios: entrega conrmada, livre de erros e no duplicada de dados de usurio; fragmentao de dados em conformidade com o MTU descoberto do caminho; entrega seqencial de mensagens de usurio em mltiplos uxos, com opo para entrega por ordem de chegada de mensagens de usurio individuais; empacotamento opcional de mltiplas mensagens de usurio em um nico pacote SCTP; e tolerncia a falhas de rede atravs do suporte a multicaminhos em qualquer ou ambas as extremidades de uma associao".

3.1. Associaes e uxos (streams) Dois terminais estabelecem uma associao SCTP, e no uma conexo como em TCP. Isso porque cada conexo TCP possui apenas um uxo full-duplex; j uma associao SCTP possui um nmero arbitrrio de uxos, negociado entre as partes na criao da associao. Cada uxo SCTP um canal de comunicao unidirecional. Pode perfeitamente haver um nmero desigual de uxos para cada direo. Uma associao SCTP que pretenda simplesmente emular TCP usa dois uxos, um em cada direo. Diferente do TCP, no existe em SCTP o estado meio-fechado (half-closed) nem para associaes nem para uxos.

28

3.2. Mensagens indivisveis A denio do SCTP fala em transmisso de mensagens, ao invs de octetos. Isso porque cada mensagem recebida atomicamente, como um bloco indivisvel, exatamente da forma que foi transmitida. A aplicao nunca receber a mensagem pela metade, ou em pedaos. Nesse aspecto, o SCTP parece um servio de datagrama conrmado, pois as aplicaes tm a garantia da atomicidade da mensagem. No caso do UDP, a garantia da atomicidade incidental pois a mensagem tem de caber no datagrama, que sempre entregue (ou perdido) atomicamente. O TCP no oferece nenhuma garantia do gnero. Os dados so transmitidos como uma seqncia no formatada de octetos, fornecendo aplicao a metfora de um enlace serial assncrono 100% convel. Cabe s aplicaes interpretar a seqncia de octetos e separar as mensagens contidas nela, baseando-se unicamente nos dados. O mais prximo que o TCP oferece em termos de separao de mensagens o ag PSH (obsoleto) e o estado meio-fechado da conexo. Assim como o TCP, o SCTP conrmado; as mensagens so entregues na ordem da transmisso e sem duplicaes. As mensagens podem ter tamanho virtualmente ilimitado (at 232 1 octetos); o protocolo encarrega-se de fragmentar a mensagem em diversos datagramas SCTP e remont-la no destino. Nada impede a aplicao de ignorar completamente a formatao em mensagens e tratar os dados como uma seqncia de octetos, ao estilo TCP. Mesmo assim, a vazo bruta do SCTP comparvel a TCP dado o mesmo cenrio de rede. Ordem de entrega das das mensagens O SCTP um protocolo conrmado tal qual TCP. Os algoritmos de reordenamento, timeout e retransmisso de pacotes, controle de congestionamento e descoberta do PMTU, tambm so implementados no SCTP. O algoritmo de controle de congestionamento realmente o mesmo do TCP, pois comprovadamente ecaz, e o uso do mesmo algoritmo assegura lealdade na convivncia entre os dois protocolos (STEWART & XIE, 2002). Em TCP, a seqncia de octetos sempre entregue na ordem estrita em que foi remetida. Isso uma garantia importante: se uma seqncia de octetos for embaralhada, torna-se intil. Porm se vrias mensagens forem transmitidas atravs de uma mesma conexo, a perda de um pacote IP pode atrasar a entrega de todas as mensagens problema conhecido com Head-of-Line Blocking.

29

Um exemplo corriqueiro uma requisio mltipla HTTP atravs de uma nica conexo TCP. Se o servidor devolver dez arquivos, cada arquivo contido em aproximadamente um datagrama, e o primeiro datagrama perder-se, a entrega dos ltimos nove datagramas (e portanto de nove arquivos) ser adiada at que o pacote perdido seja retransmitido. J no SCTP, as mensagens so entregues aplicao na ordem em que foram transmitidas, apenas dentro do contexto de cada uxo. Mensagens pertencentes a uxos diferentes no so necessariamente entregues na ordem da transmisso. Aplicando o exemplo do HTTP ao SCTP, pode-se usar dez uxos, um por arquivo solicitado. A perda de um datagrama atrasa apenas a entrega das mensagens de um nico uxo; o navegador pode receber e exibir os outros nove arquivos, enquanto o SCTP providencia a retransmisso do pacote perdido. O TCP fornece a metfora de mensagem urgente, ou fora-de-banda, entregue separadamente da seqncia principal. Porm essa mensagem de apenas um octeto por pacote TCP. E se a aplicao no ler o octeto urgente logo, uma nova mensagem urgente sobrescreve a primeira. Praticamente nenhum protocolo de aplicao faz uso desse recurso. Em SCTP tambm existe a mensagem urgente que, embora atrelada a um uxo, entregue assim que recebida (fora de ordem), mesmo que haja outras mensagens esperando por retransmisso. A mensagem urgente SCTP pode ter tamanho arbitrrio; a aplicao pode emit-las em qualquer nmero; no h perda de mensagens urgentes se a aplicao demorar-se em l-las. Se a aplicao capaz de lidar com mensagens desordenadas, ou mesmo no se importa com a ordem de chegada delas, pode remeter todas as mensagens de um uxo como urgentes, de modo a evitar qualquer atraso por perda de pacotes. 3.3. Multicaminhos (multi-homing) Outro recurso totalmente novo do SCTP em relao aos demais protocolos de transporte o suporte direto a multicaminhos. O computador multi-homed aquele ligado a duas ou mais redes IP, sem necessariamente ser um roteador. Particular importncia tem o computador ligado por dois ou mais caminhos Internet mundial, por proporcionar tolerncia a falhas e garantir a continuidade do servio. Via de regra, para uma entidade que no seja um Autonomous System (AS), estar ligado por vrios caminhos Internet no proporciona conabilidade s conexes TCP

30

e UDP em si. A rota para cada endereo do computador multi-homed esttica. Se um enlace cair, as conexes atreladas quele endereo tm de ser fechadas, e ento reabertas para o outro endereo. O servio continua, porm custa de transtorno ao usurio e/ou complexidade na aplicao. Se a entidade for um AS, dependendo dos acordos que ela tem com os AS adjacentes, o roteamento dinmico BGP encarrega-se de achar uma rota alternativa para o endereo, e as conexes em andamento no morrem. O SCTP implementa tolerncia a falhas para a associaco, sem necessidade da entidade ser um AS. Cada terminal informa ao outro uma lista de IPs que so seus endereos na rede. O IP utilizado durante a criao da associao o IP primrio, principal canal de comunicao com o terminal remoto, que provavelmente foi obtido via resoluo DNS. Os demais IPs informados so secundrios, e so utilizados caso falhe a comunicao com o IP primrio. Essa hierarquia entre IP primrio e secundrios vai ao encontro de um outro caso tpico de multicaminhos: computador ligado a um enlace primrio terrestre (rpido e barato) e a outro enlace por satlite (caro, lento e com alta latncia). O SCTP controla o estado dos diversos IPs do terminal remoto por mecanismos de heartbeat, de modo a sempre conhecer a situao de cada caminho e fazer dedues (e.g. se todos os caminhos aparentemente falharam mais provvel que o prprio terminal remoto tenha falhado, e no as redes). O suporte direto do SCTP a multicaminhos facilita muito a implantao de alta disponibilidade de rede para uma ampla gama de servios da Internet, o que de outra forma seria possvel apenas se a entidade fosse um sistema autnomo (AS), com todos os custos e responsabilidades administrativas associados. ( interessante notar que a pilha OSI tambm oferece esse recurso.) O SCTP permite inclusive que uma mesma associao utilize simultaneamente caminhos IPv4 e IPv6. Tambm permite que o endereo seja informado para o participante remoto como um nome DNS. (Estes ltimos recursos so de implementao opcional.) Como j foi dito, o algoritmo de controle de congestionamento do SCTP essencialmente o mesmo do TCP. Talvez a principal diferena em relao a TCP seja o suporte a multicaminhos, pois cada caminho tem sua prpria latncia, taxa de perda de pacotes etc. A existncia de mltiplos caminhos tambm abre espao para melhorias nos algoritmos de retransmisso, que ainda so objeto de estudo.

31

3.4. Extenses propostas ao SCTP O SCTP facilmente extensvel. Graas a isso, pode evoluir rapidamente sem quebrar compatibilidade com verses anteriores. Tal caracterstica estimula pesquisadores do mundo todo a propor extenses. Muitas acabaram sendo rejeitadas, a maioria por total descabimento. No entanto, algumas extenses a priori rejeitadas so realmente interessantes, e continuam sendo objeto de debate, e com chances de serem aceitas no futuro. Tambm interessante notar que, devido extensibilidade do SCTP, fcil a qualquer implementao oferecer extenses fora da denio ocial do protocolo. Toda extenso rejeitada pelo IETF tem a segunda chance de tornar-se um padro de fato, e assim forar uma reavaliao por parte do IETF. Tal fato deu-se com a extenso PRSCTP (STEWART et al., 2003a). Conabilidade parcial Mensagens ou uxos no conrmados teriam essencialmente as mesmas caractersticas do UDP. Porm, como existem dentro do contexto de uma associao SCTP, teriam vantagens importantes: maior segurana contra alguns tipos de ataque; suporte embutido a multicaminhos; mensagens conrmadas de sinalizao/controle podem car atreladas mesma associao; vrias mensagens pequenas, conrmadas ou no, podem ser empacotadas num mesmo datagrama SCTP; facilidade no tratamento em roteadores NAT. Tal extenso tornaria o SCTP particularmente adequado para VoIP, considerando as limitaes da Internet atual. H duas propostas semelhantes nessa direo: USCTP (XIE et al, 2001) e PR SCTP (STEWART et al, 2003a). Em ambas, guram Stewart e Xie entre os autores, os principais criadores do protocolo SCTP. A extenso USCTP (Unreliable SCTP) prope a negociao de uxos no conrmados durante a criao da associao. Todas as mensagens de um uxo no conrmado seriam conseqentemente no conrmadas e sem garantia de entrega ordenada.

32

A extenso PRSCTP (SCTP Partial Reliability) prope o relaxamento seletivo de garantias em mensagens individuais. Nessa proposta, podem conviver no mesmo uxo mensagens conrmadas e no conrmadas, assim como j convivem hoje mensagens ordenadas e urgentes. A aplicao pode modular a conabilidade da mensagem em quatro nveis:

conrmada (existente no SCTP original); conrmada sem garantia de ordenamento (existente no SCTP original); conrmada com prazo de validade; conrmada sem garantia de reordenamento e com prazo de validade.

Ambas as propostas foram a priori rejeitadas porque o SCTP , por denio um protocolo conrmado, e julgou-se que adicionar conabilidade parcial seria conitante com os demais objetivos do protocolo. Mas o PRSCTP acabou ocialmente aceito e normatizado na RFC 3758 (STEWART et al., 2004b). O suporte a esta extenso opcional. Mesmo desde antes da RFC, algumas implementaes j ofereciam esta extenso, com variados graus de maturidade. A verso nal do PRSCTP relativamente simples de adicionar a qualquer implementao SCTP. Basta duas alteraes principais:

Novo trecho avanar TSN, que indica ao terminal remoto que a janela de recepo deve ser avanada, pois algumas mensagens pendentes no sero mais entregues; Novo trecho suporte ao avano de TSN includo em INIT/INIT-ACK que indica ao terminal remoto o suporte ao mecanismo descrito supra; Na API, mudar a semntica do prazo de validade. No SCTP normal, o prazo de validade s pode invalidar mensagens em la cuja transmisso ainda no foi tentada. No PRSCTP, mensagens vencidas sero expiradas mesmo que sua transmisso j tenha sido tentada.

A extenso s pode ser usada se suportada pelas duas pontas. De acordo com as regras de tratamento de trechos desconhecidos, a pilha SCTP que no suporta PRSCTP retornar um erro recupervel ao receber o trecho suporte ao avano de TSN, o que indica ao terminal remoto a inexistncia da extenso.

33

Um uxo com caractersticas semelhantes a UDP pode ser emulado atravs de mensagens sem garantia de reordenamento e com prazo de validade igual ao RTT da rede. Como a aplicao quem atribui o prazo de validade das mensagens em PRSCTP, ela ter de monitorar o RTT da associao e/ou interpretar os avisos de mensagens no transmitidas por timeout, preocupaes que no existem em UDP. (Como a prpria API do SCTP oferece recursos de monitoramento do RTT, a aplicao ao menos no precisa calcular o RTT por conta prpria.) Tambm no possvel utilizar multicast e broadcast com PRSCTP. O PRSCTP oferece duas vantagens importantes sobre UDP: mantm os algoritmos de controle de congestionamento do SCTP, e garante lealdade com TCP. Numa situao de congestionamento severo de rede, a maioria das mensagens expiraria ainda na la de transmisso, aliviando a rede. Nessa mesma situao, todos os pacotes UDP remetidos pela aplicao seriam transmitidos, ainda que descartados nos roteadores intermedirios, piorando o congestionamento e potencialmente tornando o trfego desleal em relao a outras conexes. Na API BSD/Sockets, e possivelmente em outras APIs, transmitir um pacote UDP no bloqueia; leva apenas o tempo necessrio para o pacote ser enleirado na camada de enlace. A aplicao pode transmitir pacotes UDP to rpido quanto suportado pelo enlace diretamente conectado ao computador. (Naturalmente, no existe qualquer garantia que os roteadores intermedirios sero capazes de lidar com esse trfego.) Se este comportamento desejado pela aplicao, ela deve usar UDP. Do contrrio, deve usar protocolos com controle de congestionamento como TCP ou SCTP. Criao de uxos sob demanda O nmero de uxos em cada sentido combinado entre as partes durante a criao da associao, e permanece imutvel at o encerramento. Isso perfeitamente adequado para protocolos de aplicao como HTTP, onde o nmero de requisies conhecido no momento da associao. Em outras aplicaes, o nmero de uxos necessrios no conhecido no estabelecimento da associao. A alternativa atual reservar um nmero arbitrariamente grande de uxos, mesmo que a maioria deles nunca seja usado. Uma soluo proposta para esses casos a criao sob demanda de uxos. Do ponto de vista do aplicativo, a criao sob demanda funcionaria como a abertura de vrias conexes TCP com o servidor, porm com sobrecarga muito menor. Um nmero arbitrariamente grande de uxos ociosos no aumenta, a princpio, o consumo de memria no kernel do sistema operacional. Isso signica que os uxos

34

sob demanda podem ser ecientemente implementados. Mas tambm signica que a reserva prvia de um grande nmero de uxos tambm pode ser eciente e no demanda mudanas no protocolo SCTP. Assim, embora essa proposta tenha uma certa elegncia, dicilmente ser admitida ao SCTP. Estado meio-fechado (half-closed) para associaes Em TCP, qualquer dos participantes pode fechar a conexo apenas no sentido da transmisso, continuando a receber dados at que a conexo seja denitivamente encerrada. Nesse intervalo, a conexo est fechada em apenas um sentido, da o nome. O SCTP no possui esse recurso. Aqueles que apiam a deciso de design do SCTP apontam que o estado meiofechado um apndice desnecessrio, pois os protocolos de aplicao devem basearse unicamente nos dados para identicar o m da transmisso. Alm disso, o SCTP transmite mensagens de forma indivisvel: no existe necessidade de sinalizar m-demensagem na camada de transporte, pois fcil implementar uma mensagem de m de transmisso. J outros consideram o uso do estado meio-fechado do TCP uma forma legtima e simples de um aplicativo sinalizar m de transmisso. Alm do que sua inexistncia no SCTP diculta a adaptao de alguns protocolos de aplicao. O estado meio-fechado refere-se s associaes. No faz sentido para os uxos pois so unidirecionais e seu tempo de vida exatamente o mesmo da associao. Balanceamento de carga O projeto RivuS (vide RIVUS) prope uma extenso onde mltiplos caminhos possam ser utilizados no apenas para redundncia mas tambm para balanceamento de carga. A extenso ativada mediante solicitao da aplicao. A transmisso de pacotes seria feita de forma balanceada para todos os endereos IP do destino, e no apenas para o endereo ativo. Assim, todos os enlaces ativos seriam plenamente utilizados todo o tempo, aumentando a vazo. Recongurao dinmica de IP (AddIP) Esta extenso proposta por STEWART et al. (2003b) prev adio e excluso de endereos IP secundrios em uma associao ativa, bem como a redenio do IP primrio.

35

A motivao da proposta so os equipamentos que podem sofrer recongurao dinmica do endereo IP, bem como adio e remoo de interfaces de rede, num ambiente com associaes de vida longa e criticamente necessrias. Esta extenso j est presente em algumas implementaes. Redes por satlite Os enlaces por satlite possuem um produto latncia largura de banda muito alto, e uma latncia particularmente alta. Para esses enlaces, interessante:

aumentar o nmero inicial de datagramas transmitido pelo algoritmo slow start, se o enlace for convel o bastante; utilizar uma janela de recepo (rwnd) maior. Como isso ocupa memria do kernel, deve ser feito apenas para as associaes onde tal expediente traga dividendos de performance; aumentar a estimativa inicial do round-trip time (RTT) e do timeout de transmisso (RTO); se a perda de pacotes for grande e constante (o que caracteriza enlace pouco convel, mas seria a priori interpretado como congestionamento), ajustar o algoritmo de controle de congestionamento situao.

A pilha TCP/IP no sabe nada, nem procura descobrir, sobre as camadas fsicas que lhe servem de meio. A aplicao deve explicitamente solicitar ao SCTP que modique os valores dos algoritmos de congestionamento para funcionar melhor via satlite. Requisio de camada de adaptao STEWART et al. (2003b) prope um novo trecho que permite indicar ao terminal remoto qual a camada de adaptao necessria (M2UA, M3UA etc.) para tratar as mensagens. Este trecho transmitido juntamente com INIT ou INIT-ACK. A camada de adaptao pode apenas ser solicitada na criao da associao; no pode ser solicitada/alterada numa associao estabelecida. Este recurso atua em conjuno com o parmetro identicador de protocolo presente no trecho DATA, permitindo ao SCTP interagir perfeitamente com o SS7, sem a utilizao da metfora da porta bem conhecida que no existe em SS7.

36

previsto que a lista de cdigos de camada de adaptao sejam mantida pelo IANA, a exemplo do que acontece com os nmeros de porta. A implementao SCTP deve considerar o cdigo como opaco; responsabilidade da aplicao interpret-lo ou ignorlo. 3.5. Implementaes Um grande atrativo do protocolo MDTP, que deu origem ao SCTP, foi a implementao de referncia. Essa implementao foi a base de testes das mudanas sugeridas ao MDTP, que culminaram no SCTP, e continua sendo mantida pelos autores pelo menos at a data deste trabalho. Como ela user-level e utiliza apenas chamadas padro POSIX, funciona em qualquer sistema operacional compatvel com POSIX. A implementao do protocolo de transporte fora do kernel diminui a performance, mas facilita a manuteno, portabilidade e distribuio do software. Para o sistema operacional Windows, oferecida ao menos uma implementao comercial, tambm user-level e distribuda em forma de biblioteca. A maioria dos UNIXes comerciais tm trabalhado em implementaes kernel-level nativas para o SCTP. Tambm h implementaes comerciais para UNIX. Quanto aos sistemas operacionais de livre distribuio, h pelo menos quatro iniciativas de implementao do SCTP, todas kernel-level:

LK-SCTP: para o Linux, coligada ao projeto KAME e em estgio prximo de produo; KAME: para o FreeBSD. O projeto KAME tambm implementa protocolos IPv6 e IPSEC, com destacada qualidade, a ponto de o Linux ter adotado essas implementaes como referncia; RIVUS: para todos os BSD de livre distribuio; OpenSS7: projeto que visa implementar uma pilha SS7 de livre distribuio (ainda em estgio imaturo) que codicou sua prpria verso do SCTP para o Linux.

Uma lista completa e atualizada pode ser obtida em SCTP.ORG.

4. Aplicabilidade do SCTP
4.1. SCTP em substituio a TCP Custos e benefcios O SCTP pode ser visto como uma evoluo do TCP (STEWART & XIE, 2002). Qualquer aplicao que utilize TCP tambm pode usar SCTP, com resultados iguais ou talvez melhores. Essa possibilidade to concreta que as portas de servios TCP bem conhecidos registradas junto ao IANA (e.g. porta 80 para Web, 21 para FTP etc.) so automaticamente reservadas em SCTP para a mesma aplicao. Em uma simples troca de TCP para SCTP, sem nenhuma mudana na adaptao ao transporte, a aplicao adquire de plano as vantagens do checksum CRC-32c (resistncia corrupo de dados), e do recurso de multicaminhos (tolerncia a falhas de rede). O SCTP tambm trabalha mais duro que o TCP para manter a associao aberta. Todas essas vantagens so colhidas praticamente sem custo de manuteno nas implementaes (vide ANEXO 3). Para fazer uso dos uxos, atomicidade das mensagens e mensagens urgentes, a adaptao ao protocolo de transporte tem de sofrer mudanas, com correspondente impacto nas implementaes. Se se pretende que a adaptao tenha adoo generalizada, tambm ser necessrio submeter a mudana ao escrutnio pblico, culminando com a publicao de uma RFC. Cabe uma anlise de custo/benefcio bem mais cuidadosa. Os uxos SCTP aproveitam a qualquer protocolo de aplicao que faa uso de vrias conexes TCP em paralelo para executar uma nica tarefa. O uso de uma nica associao economiza recursos, melhora a lealdade entre usurios diferentes e facilita o tratamento em roteadores NAT. A atomicidade de mensagens traz benefcios para protocolos onde as mensagens sejam enquadrveis numa estrutura da linguagem C e/ou tenha tamanho previsvel, pois elimina completamente a necessidade da separao de mensagens na camada de aplicao. Juntamente com cada cada mensagem atmica SCTP possvel transmitir um identicador de protocolo, de 32 bits. um meta-dado que facilita a tarefa de entregar ecientemente a mensagem a seu tratador. Tambm possvel usar o recurso de mensagem urgente se for til aplicao.

38

Mensagens com tamanho imprevisvel (potencialmente muito grande, como por exemplo um arquivo inteiro) no devem ser transmitidas atomicamente, pois a implementao pode impor limites relativamente estreitos ao tamanho mximo da mensagem SCTP (vide ANEXO 2). Esse tipo de mensagem deve continuar sendo tratada inteiramente na camada de aplicao. HTTP O protocolo de aplicao HTTP muito simples, o que favoreceu sobremaneira sua popularidade. Basicamente, o cliente requisita um arquivo do servidor, e o servidor devolve o arquivo desejado, em formato binrio. Feito isso, a conexo TCP fechada. Na requisio, o cliente geralmente anexa uma lista de parmetros informativos sobre o sistema operacional e o navegador. Dependendo da requisio, tambm so passados parmetros de usurio e.g. os dados de preenchimento de um formulrio HTML. A presena dessa lista de parmetros no afeta a simplicidade do protocolo, pois de competncia do servidor interpretar essa lista como lhe aprouver. Numa pgina Web tpica, h uma pgina HTML base que contm o texto, mais um nmero relativamente elevado de elementos grcos. Cada um desses elementos um arquivo separado no servidor, que deve ser individualmente requisitado pelo cliente. H dois mtodos de requisitar todos esses elementos. A forma primitiva, suportada por todo cliente e servidor HTTP, estabelecer uma conexo TCP/IP para cada requisio. Embora muito simples, esse mtodo possui, segundo ARIAS-RODRIGUEZ, srias desvantagens:

Consome muitos recursos no cliente e em particular no servidor, devido ao grande nmero de conexes TCP abertas. Como o nmero de conexes TCP simultneas limitado pelo kernel, um servidor HTTP muito requisitado pode rapidamente saturar; O trfego gerado desleal em relao a outros servios, pois abre diversas conexes para uma nica tarefa e indiretamente aloca mais largura de banda para ela; A quase totalidade de clientes HTTP (navegadores, proxies etc.) procura limitar o nmero de conexes simultneas a um mesmo servidor. Na medida que uma encerra, outra aberta. Isso mitiga o problema mas adiciona complexidade aos clientes; A determinao do nmero mximo de conexes a um mesmo servidor subjetiva e d margem a deslealdade de um navegador perante outros;

39

Tambm h desperdcio de recursos da Internet, pois cada arquivo, por menor que seja, implicar no trfego de no mnimo nove pacotes IP (sete para iniciar e terminar a conexo TCP, e no mnimo dois para transmisso de dados HTTP teis).

Pode-se utilizar a extenso do HTTP que permite seqenciar vrios arquivos atravs de uma nica conexo TCP/IP. Este mtodo resolve de forma efetiva o excesso de conexes TCP/IP, porm:

adiciona complexidade s aplicaes, que tm de interpretar a seqncia de caracteres e separar as diversas requisies e arquivos, bem como tratar a ocorrncia de erros e omisses; potencializa o Head of Line Blocking. Se o servidor HTTP entregar dez arquivos, e um pacote IP do primeiro arquivo for perdido, a entrega dos outros ser adiada at que esse pacote perdido seja retransmitido.

Todos os problemas acima so resolvidos pela utilizao de uxos SCTP:

cada uxo de transmisso contm uma requisio, e cada uxo de retorno contm um arquivo; o atraso de um uxo, causada pela perda de um pacote IP, no atrasa a entrega das demais; essa separao no causa inecincia pois vrias mensagens pequenas de uxos diferentes so empacotadas num mesmo datagrama IP; o fato de cada requisio gurar em sua prprio uxo permite simplicar os aplicativos, que no precisam separar mltiplas requisies; a sobrecarga dos terminais reduzida pois apenas uma associao entre cliente e servidor necessria; a sobrecarga de rede reduzida pois apenas uma associao precisa ser criada e destruda (7 pacotes IP), independente do nmero de arquivos transmitidos. O uso de mltiplos uxos no implica em sobrecarga.

O nmero de arquivos HTTP a requisitar, e portanto o nmero de uxos a serem usados, no conhecido seno depois de o navegador requisitar a pgina principal. Em pginas com frames, ainda necessrio requisitar as sub-pginas. Outro detalhe a ser considerado que a atomicidade de mensagens SCTP no parece ter utilidade para HTTP.

40

Sistemas de arquivos distribudos Praticamente todos os sistemas de arquivos distribudos (NFS, CIFS, CODA, AFS, Intermezzo) podem tirar proveito da atomicidade das mensagens. A bibioteca de tipos de requisies bem denida, e o tamanho mximo das mensagens limitado. A atomicidade elimina ou simplica a decodicao, e agiliza o processamento. Se o sistema de arquivos est operando em modo assncrono, todas as mensagens podem ser rotuladas como urgentes para evitar HOL blocking. Multimdia via Internet Alguns servios multimdia, at mesmo de tempo real, usam HTTP sobre TCP como meio de transporte. Embora totalmente inadequado, ainda assim utilizado, por passar facilmente em proxies, roteadores NAT e rewalls. Multimdia sobre TCP at funciona na prtica, desde que haja grande sobra de largura de banda e baixa perda de pacotes. Mas cedo ou tarde ocorre um congestionamento mais severo e a ressincronizao torna-se impossvel. Isso particularmente verdadeiro para multimdia em tempo real, onde a gerao de dados no pra e os dados retransmitidos so simplesmente jogados fora pelo receptor, pois sua validade j expirou. O uso de SCTP em lugar de TCP, embora tambm inadequado para esse m por tambm ser conrmado, traria algumas vantagens marginais:

o uxo multimdia poderia ser mandado integralmente em mensagens urgentes, que podem ser entregues fora de ordem, o que evita o HOL blocking (desde que o protocolo de aplicao seja capaz de lidar com uxo fora de ordem); a noticao do SCTP acerca de pacotes perdidos mais elaborada, o que potencialmente economiza retransmisses; os limites mnimo e mximo do RTO (timeout de retransmisso) podem ser alterados para melhor adequar-se tarefa (porm, muito cuidado deve ser tomado para no tornar o uxo desnecessariamente agressivo).

O SCTP torna-se ideal para multimdia em tempo real, melhor que TCP e UDP, quando implementa a extenso de conabilidade parcial (PRSCTP).

41

4.2. SCTP em substituio a UDP Algumas literaturas distinguem UDP de TCP classicando o primeiro como um protocolo sem conexo. Na verdade, existem sim conexes UDP, identicadas unicamente pelos endereos e nmeros de porta; do contrrio no seriam tratveis por roteadores NAT; mas o UDP delega aplicao a responsabilidade administrativa pelas conexes. O que parece uma fraqueza pode ser uma grande vantagem. As conexes TCP e associaes SCTP residem na memria do kernel, que um recurso escasso. As conexes UDP residem na aplicao, que tem sua disposio memria virtual e outras amenidades. Em TCP/IP, a difuso (broadcast e multicast) no-conrmada, e s pode ser utilizada por protocolos de transporte no conrmados. O motivo de usar-se difuso desonerar o transmissor de conhecer nominalmente cada um dos receptores, e por extenso evitar o custo de uma conexo por receptor. Novamente o ponto livrar-se da responsabilidade pelas conexes, desta vez transferindo o nus para a camada de enlace e/ou para os roteadores intermedirios. Em aplicaes usurias de UDP onde ocorre grande nmero de conexes de vida muito curta e baixo trfego de dados o exemplo perfeito DNS no h vantagem em migrar para SCTP. O mesmo para aplicaes que fazem uso de broadcast e multicast. Sem a extenso de conabilidade parcial (PRSCTP), so poucas as oportunidades de usar SCTP em lugar de UDP. No caso especco do DNS, apenas as conexes de transferncia de zona (que sempre so TCP, inclusive por motivos de segurana) e a conexo de uma estao de trabalho com o seu servidor DNS cache (que de longa durao) teriam alguma vantagem em usar SCTP. UDP no oferece por conta prpria nenhuma garantia de reordenamento e retransmisso. Embora isso traga a vantagem marginal de evitar o head-of-line blocking, perda e desordem de dados so sempre indesejveis. Cada aplicao baseada em UDP tem de compens-las de alguma forma. Com a extenso PRSCTP de conabilidade parcial, cria-se oportunidade de substituio do UDP, em aplicaes que criem conexes de vida mais longa e/ou trfego de dados expressivo. Exemplos: multimdia (em tempo real ou no) via Internet e telefonia sobre IP. Tais aplicaes teriam enorme vantagem em utilizar PRSCTP, pois desonera a aplicao de algumas tarefas, e o trfego de sinalizao (conrmado) pode trafegar pela mesma associao que o contedo.

42 Tambm mais fcil para o roteador NAT tratar uma associao SCTP nica, do que tratar um uxo TCP mais uxos UDP associados. Para o roteador NAT saber que determinado uxo UDP relacionado ao uxo TCP de controle (como acontece por exemplo no protocolo H.323), precisa analisar o trfego da camada de aplicao o que viola a arquitetura de camadas e ineciente. 4.3. Novas possibilidades de uso do TCP/IP e da Internet O SCTP opera sobre IP, e sujeito as limitaes deste. Cada novo recurso do SCTP pode ser implementado na camada de aplicao. Por que ento implementar ainda outro protocolo de transporte, se ele no cria nada por si s? O SCTP no exatamente um criador de novas aplicaes, mas sim um promotor de aplicabilidade, pois compila grande nmero de recursos e melhorias, de forma ordenada, universalmente compatvel, aliviando a complexidade dos protocolos de aplicao, e com grande potencial de performance se for implementada no kernel. Tomando como exemplo o recurso de multicaminhos, que um recurso SCTP transparente aplicao. perfeitamente possvel a uma aplicao implementar por si esse recurso. Porm ela teria de ser baseada em UDP, e implementar tambm o controle de erros. Ou ento basear-se em TCP e criar um produto cartesiano de conexes TCP, lidar a com a burocracia de administrao dessas conexes, retransmitir dados perdidos no caminho quando uma conexo cair etc. E uma vez que uma aplicao conseguisse implementar e testar multicaminhos, esse recurso no aproveitaria a nenhuma outra aplicao. Sinalizao telefnica O transporte de sinalizao telefnica a grande motivao da existncia do protocolo SCTP. Praticamente todos os recursos do SCTP, bem como a boa parte dos drafts posteriores, objetivam atender a esse pblico-alvo. A integrao do SCTP com redes de telefonia explanada em detalhes na seo 2.2. Dispositivos portteis, eletrnica embarcada e redes fabris O uso de TCP/IP nesse tipo de aplicao seria desejvel pelo baixo custo e grande disponibilidade de hardware, software e massa crtica de conhecimento relacionados. Alm disso, abre toda uma gama de possibilidades de integrao a computadores de uso geral, a outras redes ou mesmo Internet. Mas o protocolo de transporte TCP , porm, inadequado a esse tipo de rede. O protocolo UDP muito carente de recursos. Nenhum dos dois protocolos oferece, ao mesmo tempo, garantia de entrega, tolerncia a falhas e baixa latncia caractersticas do SCTP.

43

A especicao do SCTP exvel permite s implementaes restringir o nmero mximo de uxos, bem como limitar o tamanho da mensagem ao PMTU, tornando-as enxutas e apropriadas a dispositivos limitados em memria e CPU. Enlaces via satlite O TCP tem fraco desempenho tpico em redes via satlite, por uma combinao dos seguintes motivos:

uso de janelas de transmisso muito pequenas as aplicaes no tm a cultura do uso da opo de escalonamento de janela, nem ao menos do uso de buffers de recepo acima do default; algoritmos de congestionamento no adaptados a enlaces wireless, que perdem muitos pacotes; a conrmao seletiva (SACK) do TCP limitada, alm do suporte a SACK ser opcional; excessivo nmero de conexes concomitantes em aplicaes tpicas (e.g. HTTP), cada uma incorrendo em sobrecarga e lentido inicial devido ao slow start.

O uso de um proxy nesse tipo de enlace melhora a experincia do usurio porm limita sua aplicabilidade. O SCTP suporta grandes janelas de transmisso (embora ainda dependa da iniciativa das aplicaes para us-las), potencializa o uso de menor nmero de associaes dada a mesma tarefa, e possui um SACK mais elaborado. Tais recursos so padro do protocolo, no opcionais como no TCP. A adaptao dos algoritmos de congestionamento ao enlace via satlite ainda objeto de discusso (vide 3.4).

5. Comparao de desempenho com TCP

5.1. Objetivos Os testes desenvolvidos neste captulo objetivam comparar o desempenho do SCTP frente ao TCP, nos critrios de vazo e latncia. O TCP foi escolhido como adversrio por ser o protocolo mais utilizado na Internet hoje, por ser um protocolo conrmado como o SCTP, e por praticamente todos os protocolos de aplicao existentes, que poderiam aproveitar-se das caractersticas avanadas do SCTP, hoje usam TCP como transporte. Diversos cenrios de rede foram construdos, utilizando-se recursos de hardware e software. Foram objeto de variao: largura de banda, taxa de perda constante de pacotes, taxa de duplicao de pacotes, latncia de rede e intermitncia de funcionamento da rede. Em cada cenrio de rede, duas caractersticas bsicas foram testadas: vazo e latncia. Em conjunto, elas fornecem dados sucientes para concluir sobre o desempenho do SCTP em cada cenrio de rede. Vazo o volume de dados trafegado por unidade de tempo. A maioria dos usurios percebe mais claramente a vazo que a latncia (e.g. acompanhando o progresso de um download), e toma vazo e desempenho por sinnimos, embora a vazo isoladamente no garanta bom desempenho. Em todos os testes deste captulo, a unidade de vazo utilizada o kbps (1000 bits por segundo), por ser a mais comumente utilizada em redes de computadores, ainda que o usurio nal costume perceber a vazo em KBytes/s. Latncia o tempo decorrido entre a formulao de uma requisio, e o recebimento da resposta. Embora isto no seja bvio para o usurio nal, a latncia o parmetro de desempenho mais importante num sistema cliente/servidor, em particular quando as requisies so serializadas (i.e. a prxima requisio depende do resultado da anterior). Em todos os testes deste captulo, a unidade de latncia o microssegundo (s). Em alguns testes, onde a latncia de rede foi objeto de variao, a latncia apurada no teste foi denominada latncia de transao, pois ela simula uma transao cliente/servidor. Usou-se pontualmente esta denominao para evitar qualquer confuso entre as duas grandezas.

45

5.2. Aplicativos construdos para o teste Os aplicativos utilizados nos testes deste captulo foram escritos pelo prprio autor, nas linguagens C e C++, e seu cdigo-fonte pode ser encontrado no CD anexo dissertao. Todos os aplicativos descritos abaixo permitem variar o tamanho das mensagens transmitidas, nmero de uxos utilizados em SCTP, endereos para associao (bind) e o volume total trafegado em bytes. Exceto quando explicitamente armado o contrrio, todos os testes utilizaram os soquetes estilo TCP. A API BSD/Sockets oferece acesso ao SCTP atravs de soquetes estilo TCP e estilo UDP. Para maiores informaes, consulte o ANEXO 3. Por padro, os aplicativos trafegam 100 milhes de bytes, em cada direo, por rodada. Em algumas situaes, quando o cenrio simulou uma rede muito lenta, e o uso de um volume menor de dados no prejudicaria a qualidade das amostras, esse volume foi reduzido para diminuir o tempo necessrio execuo do teste. TCPM: Separao de mensagens para TCP Os aplicativos de teste permitem utilizar diversos protocolos de rede: TCP, SCTP e soquetes UNIX. No caso do TCP, pode-se utiliz-lo puro, ou empilhado com um protocolo de aplicao denominado TCPM. O TCPM foi criado especialmente para os ns deste trabalho, e possibilita a separao de mensagens na camada de aplicao. Naturalmente, isto aumenta a sobrecarga de processamento, portanto o TCPM ter desempenho menor que o TCP puro dado o mesmo cenrio de rede. O principal motivo de introduzir essa codicao/decodicao de mensagens em TCP foi tornar a comparao mais justa com SCTP, onde esse custo est sempre presente. O protocolo TCPM o mais simples possvel: um byte marcando o incio da mensagem, outro marcando o nal. Qualquer protocolo real seria mais complexo e custaria mais processamento. Para protocolos de aplicao que no separam mensagens (e.g. conexo de dados FTP), ou usem mensagens arbitrariamente longas que obriguem a separao na camada de aplicao, impor essa carga extra ao TCP seria injusto pois ela no existe na prtica. Porm, para esses protocolos, o TCP uma escolha mais adequada que SCTP. Os testes visam protocolos de aplicao onde sejam aplicveis os recursos novos do SCTP. Os testes com soquetes UNIX tambm tm a opo de utilizar o transporte puro, ou empilhado com o protocolo de aplicao UNIXM. O UNIXM idntico ao TCPM, possuindo um nome diferente apenas para melhor identicar o transporte.

46

Testes de vazo Os aplicativos construdos para o teste de vazo enviam um certo volume de bytes, divididos em mensagens individuais. O envio acontece nas duas direes; se o volume total congurado for e.g. 10MBytes, o volume total trafegado em ambas as direes ser 20MBytes. Os aplicativos no tentam sincronizar de qualquer forma os dois uxos (exceto udp_server2, vide abaixo); perfeitamente possvel que uma direo termine antes que outra, prejudicando o resultado nal do teste. Isto propositado um bom protocolo de transporte deve permitir uma comunicao full-duplex equilibrada, e o teste de vazo testa (indiretamente) esse equilbrio. Segue a lista de utilitrios de teste de vazo: tcp_server: Servidor que utiliza soquetes estilo TCP. Permite usar os protocolos soquete UNIX, TCP e SCTP. Para soquetes UNIX e TCP, ainda h a opo de codicar as mensagens (UNIXM e TCPM) de modo que sejam separveis na camada de aplicao, como seria normalmente feito na maioria dos protocolos de aplicao reais. tcp_client: Lado cliente do teste, com as mesmas caractersticas de tcp_server. udp_server: Servidor SCTP que faz uso de soquetes estilo UDP. udp_server2: Implementao alternativa de udp_server em C++, que usa um identicador opaco da associao ao invs do endereo, sendo assim mais correta para uso com multicaminhos em lugar de udp_server. O C++ foi utilizado pois a biblioteca STL facilitou a implementao da lista de clientes ativos. Por razes de lgica interna, este servidor impe uma vazo uniforme nos 2 sentidos. udp_client: Cliente que utiliza protocolo SCTP e soquetes estilo UDP. Os testes de vazo podem ser executados tanto com TCP e soquetes UNIX puros (sem separao de mensagens), quanto com TCPM e UNIXM (com separao de mensagens). Nos cenrios de loopback e rede 100Mbps, ambas as possibilidades foram utilizadas para efeitos de comparao. Testes de latncia Os aplicativos para teste de latncia, da mesma forma que os testes de vazo, trafegam um dado volume em ambas as direes, dividido em mensagens de tamanho xo. A diferena que, para cada mensagem enviada pelo cliente, exatamente uma retornada pelo servidor, simulando assim um sistema cliente/servidor tpico.

47

O lado cliente responsvel por computar a latncia total entre a remessa da pergunta e o retorno da resposta. O tempo fora desse intervalo no computado. Cada transao cronometrada utilizando-se a chamada POSIX gettimeofday() e o valor retornado ao nal a mdia das latncias. A chamada gettimeofday() tem preciso de s em computadores e sistemas sucientemente recentes. O tempo consumido pela chamada foi considerado negligencivel frente s latncias a serem mensuradas. No computador mais rpido do laboratrio de testes, a latncia da chamada foi de apenas 0,25s, e o intervalo mais curto mensurado nos testes de rede foi de 18s, portanto a sobrecarga de apenas 3% no pior caso (considerando duas chamadas por medio). Os aplicativos criados para o teste foram: tcp_server_lat, udp_server_lat,

udp_server2_lat, udp_client_lat e tcp_client_lat. Eles compartilham das mesmas caractersticas dos aplicativos correspondentes para medida de vazo. O servidor tcp_server_lat impe o uso dos protocolos de aplicao TCPM e UNIXM, pois necessrio ter meios de separar a mensagem para determinar se ela chegou completamente. Coleta de dados Nos testes de vazo, os valores exibidos nos grcos e tabelas deste trabalho so mdias de 4 passagens. Foram feitas 5 rodadas de execuo por teste; o primeiro resultado descartado e os demais compem a mdia. Nos testes de latncia, cujo valor retornado j uma mdia que converge rapidamente, apenas duas rodadas foram executadas. O valor contido nos grcos e tabelas deste trabalho a mdia das 2 rodadas. O resultado das passagens individuais, mdia e desvio padro podem ser encontrados na planilha amostras.xls do CD que acompanha este trabalho. 5.3. Sistema operacional e implementao do SCTP O sistema operacional utilizado foi o Linux, verso de kernel 2.6.10rc1 (kernel 2.6.9 atualizado com algumas mudanas que foram incorporadas ao 2.6.10 nal). Foi o kernel estvel mais recente disponvel poca dos testes. O protocolo SCTP sofreu atualizaes importantes at a verso 2.6.8, como o suporte a PRSCTP. A implementao do SCTP utilizada a LKSCTP (Linux Kernel SCTP), includa nas sries 2.4 e 2.6 do kernel do Linux. Exceto onde explicitamente armado o contrrio, o sistema operacional, o TCP e o LKSCTP foram utilizados com suas conguraes default, sem qualquer otimizao

48

de parmetros. Presume-se que a maioria dos usurios use um sistema da mesma forma, sem qualquer otimizao, e que uma congurao default sub-tima seria simplesmente percebida como um problema inerente. A importncia dos aplicativos user-level reduzida nos testes deste trabalho pois o desempenho depende majoritariamente do kernel. A distribuio utilizada foi o Conectiva Linux 10. O software user-level mais relevante o compilador C. A distribuio fornece o GCC verso 3.3.3. A implementao est sendo desenvolvida desde 2001, e j foi objeto de vrios testes independentes. Possui inclusive sua prpria biblioteca de testes de regresso, que vericam, a cada lanamento de nova verso, se todos os aspectos do protocolo esto funcionando corretamente. Porm, a maturidade ser atingida apenas quando o protocolo for largamente usado por aplicaes reais. At a data desta dissertao (2004), o principal objetivo da equipe LKSCTP produzir uma implementao correta e completa (a verso mais recente suporta PRSCTP e AddIP). O desempenho, embora j tenha melhorado bastante desde ao longo do tempo, ainda tem prioridade mais baixa. O LKSCTP no faz qualquer esforo em otimizar o consumo de memria, para o caso de aplicaes que reservem um grande nmero de uxos mas deixe-os quase todos ociosos. Um dos objetivos deste trabalho era propor tal otimizao, utilizvel de forma opcional atravs de interface setsockopt(). A adaptao do HTTP ao SCTP acabou revelando que tal otimizao seria de pouca utilidade (vide 6.2.1). A decincia mais agrante da implementao (pelo menos at a ltima verso do LK-SCTP analisada) alocar memria em blocos muito grandes para os SSN dos uxos at 256KB numa associao com 65536 uxos em cada direo, usando interfaces obsoletas (kmalloc() e __get_free_pages()). Tais interfaces alocam blocos contnuos na RAM fsica. Em situaes de RAM escassa, as pginas livres provavelmente no estaro agrupadas, e alocaes de grandes reas contnuas no sero satisfeitas. A interface atualmente recomendada para alocao dinmica dentro do kernel do Linux o slab cache, com unidades de alocao no maiores que uma pgina de RAM da arquitetura. No to simples como alocar reas contnuas, mas garante o bom funcionamento em situaes-limite. Alocao de grandes reas contnuas deve restringir-se aos drivers de dispositivo que tenham essa necessidade. 5.4. Ferramentas de simulao de rede Para modelar redes com caractersticas reais, com latncia varivel e perda de pacotes, foram utilizadas algumas ferramentas do Linux: os recursos de roteamento avanado netem e lter, e o rewall IPTables.

49

Figura 5.1: Exemplo de script para simulao de rede com latncia e perda
tc qdisc del dev eth0 root tc qdisc del dev eth0 ingress # simulao de latncia e duplicao na sada (egress) tc qdisc add dev eth0 root handle 1:0 netem delay 30ms duplicate 0.1% tc qdisc add dev eth0 handle ffff: ingress # simulao da banda, no caso 1Mbps, na entrada (ingress) # o excesso de banda descartado (drop) tc filter add dev eth0 parent ffff: protocol ip prio 1 \ u32 match ip src 0.0.0.0/0 \ police rate 1Mbit burst 100k drop \ flowid :1 tc -s -d qdisc ls dev eth0 # perda de 0,1% constante # random so aceita percentagens inteiras, ento usamos 2 filtros # para simular uma perda com decimais iptables -F iptables -N PASSODOIS iptables -A INPUT -m random --average 1 -j PASSODOIS iptables -A PASSODOIS -m random --average 10 -j DROP iptables -A PASSODOIS -j ACCEPT iptables -P INPUT ACCEPT

A disciplina de trfego netem (SHREMMINGER) possibilita introduzir latncia, perda, duplicao e reordenamento de pacotes na sada de uma interface de rede. No estado atual desta ferramenta (kernel 2.6.10rc1), os recursos de perda de pacotes e reordenamento ainda tm problemas e no podem ser usados para simulao. O gerenciamento de la lter foi utilizado para simular um canal com largura de banda reduzida, que congestiona e perde pacotes ao ser saturado. Nos testes deste trabalho ele foi posicionado na entrada de pacotes do receptor (ingress shaping), pois simula melhor uma rede congestionada. Se fosse posicionado na sada, os pacotes nem chegariam a ocupar largura de banda real. Alm disso, os protocolos de transporte do Linux detectam e reagem imediatamente a pacotes descartados logo de sada (seja por shaping ou por rewall), o que distorceria os resultados. Finalmente, o rewall IPTables foi utilizado para simular perda de pacotes (remendando assim a insucincia do netem) e a queda de link para testes com multicaminhos. O recurso de perda aleatria de pacotes no est disponvel por padro na maioria das distribuies Linux, mas prontamente disponvel como cdigo-fonte e foi incorporado ao kernel utilizado nos testes. A perda total de pacotes do canal ser a perda constante simulada no IPTables, mais a perda varivel simulada pelo ingress shaping em funo da saturao do canal. A gura 5.1 mostra um exemplo de script destinado simulao de rede com latncia e perda. O script deve ser executado nos dois computadores terminais envolvidos no teste. Em nenhum dos testes foi necessrio executar scripts em roteadores intermedirios.

50

5.5. Computadores utilizados nos testes SOLDIER: Athlon XP 1800+, placa-me ASUS A7V5X (chipset VIA KT266), 512MB RAM DDR 266MHz, uma placa de rede RTL 8139 100Mbps on-board. COP: Athlon Thunderbird 1200 MHz, placa-me ASUS A7V (chipset VIA KT133), 512MB RAM 133MHz, duas placas de rede RTL 8139 100Mbps , uma placa de rede RTL 8029 PCI 10Mbps. ARP: Pentium II 400MHz, placa-me Intel SE440BX2, 256MB RAM 100MHz, uma placa de rede RTL 8139 100Mbps, uma placa de rede PCCard Avaya Silver wireless 802.11b 11Mbps, adaptador PCIPCMCIA Ricoh. BIKER: Pentium II 233MHz, chipset de placa-me SE440BX2 para notebook, 160MB RAM 100MHz, uma placa de rede PCCard 3Com 3C589 Combo 10Mbps, uma placa de rede PCCard Avaya Silver wireless 802.11b 11Mbps. Os computadores SOLDIER e COP foram os mais freqentemente utilizados nos testes, pois eram os mais rpidos, o que minimiza a decincia das placas de rede de baixo desempenho. 5.6. Cenrios de rede Interface de loopback Na interface de loopback (endereo IP 127.0.0.1), no h perda ou latncia de comunicao de rede; o nico custo do trfego o consumo de CPU dos protocolos de rede, transporte e aplicao. Os protocolos com melhor performance so os que consomem menos CPU, e eventualmente mais otimizados em detalhes de baixo nvel (como cache hit de CPU). O soquete UNIX foi includo neste teste pois um mecanismo de comunicao interprocessos sem qualquer overhead de rede, e portanto deve indicar a maior performance possvel no equipamento utilizado. Os testes de loopback variaram o tamanho das mensagens trocadas pelos aplicativos de teste (de 10 a 10000 bytes) e o nmero de uxos SCTP (de 1 a 10000 uxos). O computador utilizado nestes testes foi o SOLDIER (Athlon XP 1800+). Rede Ethernet 100Mbps Foi utilizada uma rede Ethernet 100Mbps com switch, sem a introduo de nenhuma perda ou latncia articial. Os testes variaram o tamanho das mensagens trocadas entre os participantes, de 10 a 10000 bytes.

51

A mquina COP (Athlon 1.2GHz) foi utilizada como servidor e a mquina SOLDIER (Athlon XP 1800+) como cliente. Rede Ethernet 100Mbps com perda de pacotes Foi utilizada como base uma rede Ethernet 100Mbps com switch. Neste teste, foi introduzida uma perda articial de pacotes, na recepo (input). Assim, o pacote perdido ocupa largura de banda. O objetivo testar a adaptabilidade dos protocolos a redes com perdas. Os aplicativos usaram sempre mensagens de 500 bytes de tamanho. Os testes foram feitos com as seguintes taxas de perda de pacotes: 0%, 0,1%, 1%, 3% e 10%. A mquina COP (Athlon 1.2GHz) foi utilizada como servidor e a mquina SOLDIER (Athlon XP 1800+) como cliente. Rede Ethernet 10Mbps com latncia Foi utilizada uma rede Ethernet 100Mbps com switch. De modo a limitar a vazo em 10Mbps sem recorrer a trafc shaping por software, a comunicao ocorreu atravs de uma placa de rede 10Mbps instalada no computador COP. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. A latncia de rede foi variada entre 5ms e 300ms, o que corresponde a RTTs de 10ms a 600ms. O objetivo deste teste medir a inuncia da latncia de rede no desempenho dos protocolos. A mquina COP (Athlon 1.2GHz) foi utilizada como servidor e a mquina SOLDIER (Athlon XP 1800+) como cliente. Rede Ethernet 10Mbps com perda de pacotes e latncia Foi utilizada uma rede Ethernet 100Mbps com switch. De modo a limitar a vazo em 10Mbps sem recorrer a trafc shaping por software, a comunicao ocorreu atravs de uma placa de rede 10Mbps instalada no computador COP. Neste teste tambm foi introduzida uma perda constante de 1% dos pacotes em ambas as direes. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. A latncia de rede foi variada entre 5ms e 300ms, o que corresponde a RTTs de 10ms a 600ms. O objetivo deste teste medir a inuncia da latncia de rede no desempenho dos protocolos, na presena de uma perda constante. A mquina COP (Athlon 1.2GHz) foi utilizada como servidor e a mquina SOLDIER (Athlon XP 1800+) como cliente.

52

Rede 1Mbps com latncia e duplicao de pacotes Como base, foi utilizada uma rede Ethernet 100Mbps com switch. A largura de banda de 1Mbps foi simulada atravs de trafc shaping, que simula um congestionamento de rede e descarta pacotes que ultrapassarem a velocidade determinada. Assim, este cenrio tem perda de pacotes, mas esta perda varivel, e o controle de congestionamento do protocolo de transporte tende a zer-la. Tambm em software foi simulada uma latncia varivel de 50ms +/- 25ms (correlao de 50% entre latncias seguidas) e 1% de duplicao de pacotes. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. A mquina COP (Athlon 1.2GHz) foi utilizada como servidor e a mquina SOLDIER (Athlon XP 1800+) como cliente. Rede 1Mbps com latncia, perda e duplicao de pacotes Como base, foi utilizada uma rede Ethernet 100Mbps com switch. A largura de banda de 1Mbps foi simulada atravs de trafc shaping. Outras condies simuladas: latncia varivel de 50ms +/- 25ms (correlao de 50% entre latncias seguidas), 1% de duplicao de pacotes, perda constante de 0,1% de pacotes. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. A mquina COP (Athlon 1.2GHz) foi utilizada como servidor e a mquina SOLDIER (Athlon XP 1800+) como cliente. Rede 11Mbps wireless 802.11b ad-hoc Foi utilizada uma rede wireless 802.11b 11Mbps ad-hoc entre os computadores BIKER e ARP. Uma rede Ethernet de 100Mbps com switch, sem qualquer perda ou latncia articiais, foi utilizada entre os computadores ARP e SOLDIER. A vazo total limitada pelo enlace de menor capacidade no caminho; a latncia de rede total soma da latncia das duas redes, mais aquela eventualmente introduzida pelo roteador. Os pontos wireless caram propositadamente distantes, de modo a fornecer um canal de qualidade sofrvel. A vazo bruta unidirecional, medida experimentalmente, foi de 3Mbps. A rede 802.11b no faz comunicao full-duplex. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. A mquina BIKER (Pentium II/400 MHz) foi utilizada como cliente, e a mquina SOLDIER (Athlon XP 1800+) como servidor. A mquina ARP operou como roteador intermedirio. Rede Ethernet 100Mbps, um servidor, dois clientes simultneos

53

Tabela 5.1: Vazo em kbps, conexes loopback

Protocolo / tamanho msg. em bytes Unix UnixM TCP TCPM SCTP SCTP estilo UDP SCTP estilo UDP v. 2 10 8900 4980 11644 1802 1384 1334 1344 100 93870 43640 115320 16030 15842 15584 13160 1000 718602 218084 643522 128220 108626 109066 98902 10000 2452172 438726 1030614 265872 255372 228040 282236

Foi utilizada uma rede Ethernet 100Mbps com switch, sem a introduo de nenhuma perda ou latncia articial. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. As mquinas COP e SOLDIER foram utilizadas como clientes, e a mquina ARP como servidor. Multicaminhos 10Mbps e 11Mbps O caminho primrio de rede de 10Mbps Ethernet (a placa de rede do computador BIKER de 10Mbps). O caminho secundrio 802.11b ad-hoc, 11Mbps. A mquina ARP operou como roteador intermedirio no caminho secundrio. Nos testes de multicaminhos, o trfego do link primrio liberado por 10 segundos, a seguir bloqueado por 10 segundos. Esse ciclo mantido continuamente. Foram usadas regras de rewall e de roteamento para evitar roteamento assimtrico em qualquer dos dois estados. Nos testes dos caminhos individuais, o trfego contnuo. O tamanho das mensagens utilizado pelos aplicativos de teste foi de 500 bytes. A mquina BIKER (Pentium II/233 MHz) foi utilizada como servidor, e a mquina COP (Athlon 1.2GHz) como cliente.

5.7. Resultados 5.7.1. Interface de loopback A gura 5.2 e a tabela 5.1 exibem os resultados do teste de vazo. Como de se esperar, o TCP teve performance muito superior ao SCTP. Reputa-se isso ao clculo do somatrio CRC-32c que ocorre a cada pacote em SCTP, e a compulsria separao de

54

Figura 5.2: Vazo em conexes loopback

Vazao loopback 2500000 "unix" "tcp" "unixm" "tcpm" "sctp" "sctp-udp" "sctp-udp2"

2000000

1500000 kbps 1000000 500000

0 10 100 Tamanho da mensagem 1000 10000

mensagens que obriga uma troca de contexto no receptor para cada mensagem. Por outro lado, quando foi imposta a separao de mensagens para TCP e soquetes UNIX (TCPM e UNIXM), o desempenho de todos os protocolos cou bastante parecido. Um teste posterior, feito pelo autor, desligando-se o clculo do CRC-32c no kernel do Linux, mostrou que o ganho de desempenho surpreendentemente pequeno (10% a 15% em loopback). Isto ainda deve ser objeto de estudo mais cuidadoso, mas indica que a priori o grande responsvel pelo menor desempenho do SCTP a separao de mensagens. O uso de soquetes estilo TCP ou UDP nos programas SCTP no inuencia sensivelmente na performance. O melhor resultado do SCTP estilo UDP verso 2 devido ao sincronismo que este impe sobre as duas direes de transmisso. Os demais servidores SCTP tenderam a perder o sincronismo (i.e. uma direo terminava de transmitir muito antes que a outra). Uma surpresa do teste, no relacionada com o SCTP, foi o TCP ter vazo maior que soquetes UNIX para mensagens pequenas. No teste de latncia, trocas de contexto tm de seguir uma ordem estrita: processocliente, kernel, processo-servidor, kernel, processo-cliente. Todos os overheads (bytes de controle, custo de CPU, inecincias da implementao) cam serializados e evidenciados.

55

Figura 5.3: Latncia em conexes loopback

Latencia loopback 300.0 "sctp" "sctp-udp" "sctp-udp2" "tcpm" "unixm"

250.0

200.0 microssegundos

150.0

100.0

50.0

0.0 10 100 Tamanho da mensagem 1000 10000

Tabela 5.2: Latncia em s, conexes loopback

Protocolo / tamanho msg. em bytes UnixM TCPM SCTP SCTP estilo UDP SCTP estilo UDP v. 2 10 18,5 26,5 52,0 52,5 52,0 100 18,5 28,5 52,5 54,5 55,5 1000 27,0 34,0 72,5 73,5 75,0 10000 104,0 112,5 265,5 267,0 266,0

56

Tabela 5.3: Vazo e latncia em conexes loopback, em funo do nmero de uxos

Nmero de uxos 1 10 100 1000 10000 Vazo (kbps) 16140 16244 16128 16136 16036 Latncia (s) 51,0 51,0 53,0 53,5 51,5

Conforme a gura 5.3 e a tabela 5.2, o SCTP apresentou performance aproximadamente duas vezes menor que TCPM, no importa tamanho da mensagem. A razo mais provvel para esse desempenho inferior do SCTP o grande nmero de cpias de memria executado pela implementao. Idealmente, um protocolo de transporte deveria fazer uma, ou at mesmo zero cpias de memria. Este ideal mais difcil para o SCTP devido a suas caractersticas inerentes (CRC-32c, separao de mensagens etc.) O uso de soquete estilo TCP ou UDP no fez qualquer diferena ao SCTP. Desta forma, a escolha de um ou outro estilo pode atender unicamente convenincia do desenvolvedor, no havendo nenhum efeito colateral na performance. Para testar a vazo e latncia SCTP em funo do nmero de uxos, foram utilizadas mensagens de 100 bytes neste teste. A variao em funo do nmero de uxos praticamente nula, como mostra a tabela 5.3. Um teste levado a cabo por KANG & FIELDS demonstrou que a vazo do SCTP maior quando utilizam-se diversos uxos em paralelo, contrariando o resultado do teste deste trabalho. Mas o teste de KANG & FIELDS pressups que o protocolo de aplicao utiliza simultaneamente todos os uxos, e pode receber as mensagens de forma desordenada (i.e. sem poder prever de que uxo viria a prxima mensagem). Isto seria equivalente a marcar todas as mensagens como urgentes, de modo que sua entrega no obedecesse qualquer ordem. Os testes deste captulo pressupem que o protocolo de aplicao exige um transporte conrmado tal qual TCP, e deste modo no podemos aproveitar a entrega desordenada como estratgia de aumento de desempenho. Nos testes com o protocolo HTTP, onde diversos uxos so usados para transportar uma nica transao (pgina HTTP com os respectivos objetos acessrios), ser ento possvel colher ganhos de desempenho com esta tcnica.

57

Figura 5.4: Vazo, rede 100Mbps

Vazao rede 100Mbps 100000 90000 80000 70000 60000 kbps 50000 40000 30000 20000 10000 0 10 100 Tamanho da mensagem 1000 10000 "tcp" "tcpm" "sctp"

Tabela 5.4: Vazo em kbps, rede 100Mbps

Protocolo / tamanho msg. em bytes TCP TCPM SCTP 10 20578 15076 1952 100 91782 82114 19926 1000 90984 90886 87994 10000 89972 89954 81118

5.7.2. Rede 100Mbps Os resultados de vazo esto evidenciados na gura 5.4 e na tabela 5.4. Com mensagens grandes, a vazo tende ao mximo permitido pela rede em todos os protocolos. A vazo do SCTP menor pois o protocolo tem maior overhead inerente. Na medida em que as mensagens diminuem de tamanho, o overhead aumenta em importncia relativa, e o desempenho do SCTP ca cada vez mais prejudicado. Uma anlise do trfego de rede tambm revelou que o chunk bundling (combinao de diversos trechos de dados em um nico pacote) no est otimamente implementado no LKSCTP. A implementao empregou um pacote para cada mensagem, como se o algoritmo Nagle (NAGLE) estivesse desligado. A grande diferena em desfavor do SCTP, no teste de latncia com loopback, foi mascarada pela latncia da rede, conforme mostram a tabela 5.5 e a gura 5.5. Inte-

58

Figura 5.5: Latncia, rede 100Mbps

Latencia rede 100Mbps 2500

2000 "sctp" "tcpm" 1500

microssegundos

1000

500

0 10 100 Tamanho da mensagem 1000 10000

Tabela 5.5: Latncia em s, rede 100Mbps

Protocolo / tamanho msg. em bytes TCPM SCTP 10 101.5 128.0 100 138.5 163.0 1000 463.0 505.0 10000 1793.0 2223.0

59

Figura 5.6: Vazo em kbps, rede 100Mbps com perda de pacotes

Vazao rede 100Mbps com perdas 100000 90000 80000 70000 60000 kbps 50000 40000 30000 20000 10000 0 0 2 4 % perda pacotes 6 8 10 "tcpm" "sctp"

Tabela 5.6: Vazo (em kbps), rede 100Mbps com perda de pacotes
Protocolo / perda % TCPM SCTP 0% 90596 60773 0,1% 78846 56834 1% 57876 57030 3% 23396 46438 10% 878 852

ressante notar que a menor diferena ocorreu quando tamanho da mensagem tendeu ao tamanho do pacote de rede (mxima diluio da sobrecarga de dados). 5.7.3. Rede 100Mbps com perda de pacotes

A tabela 5.6 e a gura 5.6 evidenciam que, na ausncia de perdas, a vazo do SCTP foi bastante menor que TCP, resultado congruente com a tabela 5.4 do teste anterior levando-se em conta que o tamanho de mensagem empregado foi de 500 bytes. Na medida em que aumentam as perdas, a vazo naturalmente cai. E ento o SCTP conseguiu manter uma vazo maior em perdas moderadas (1% a 3%). Nenhuma otimizao foi tentada nem em SCTP nem em TCP neste teste. As implementaes de ambos no Linux permitem regular alguns parmetros do controle de congestionamento, mas foram simplesmente utilizados os valores padro. Possivelmente, o desempenho de ambos, em particular do TCP, podem ser melhorados se esses parmetros forem atuados.

60

Figura 5.7: Latncia, rede 100Mbps com perda de pacotes

Latencia rede 100Mbps com perdas 700000 "sctp" "tcpm"

600000

500000 microssegundos

400000

300000

200000

100000

0 0 2 4 6 Perda de pacotes em % 8 10

Tabela 5.7: Latncia em s, rede 100Mbps com perda de pacotes

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

O SCTP beneciou-se ainda de uma caracterstica do aplicativo construdo para os testes de vazo: pacotes so continuamente mandados em ambas as direes, o que permite ao SACK atuar com presteza. Apesar de ter ido bem no teste de vazo deste cenrio, o SCTP teve pssimo desempenho no teste de latncia, conforme mostram a gura 5.6 e a tabela 5.7. O principal fator desse resultado ruim a congurao default do controle de congestionamento do SCTP. O RTO (timeout) mnimo padro do LKSCTP de 1 segundo; isso aproximadamente 5000 vezes o RTT da Ethernet 100Mbps. Portanto, toda perda causa um atraso de no mnimo 1 segundo na transao, elevando muito a mdia geral. O TCP demonstrou no ter limite mnimo embutido de RTO; ele ser proporcional latncia da rede real, e portanto adaptar-se- corretamente. Quando o protocolo de aplicao troca pacotes continuamente nas duas direes, o SACK do SCTP tem a oportunidade de noticar a perda imediatamente, e o transmissor toma providncias antes do RTO. Por esse motivo o SCTP foi bem melhor no teste de vazo que no teste de latncia.

61

Figura 5.8: Vazo em kbps, rede 10Mbps com latncia de rede

Vazao rede 10Mbps com latencia 4000 "tcpm" "sctp"

3500

3000

2500 kbps 2000 1500 1000 500 0 50 100 150 200 latencia da rede (milissegundos) 250 300

O problema detectado no teste de latncia deste cenrio em particular foi o mais grave encontrado no LKSCTP. O SCTP tem uma extenso opcional para links de satlite, onde perdas severas e constantes so esperadas, mas o LKSCTP no oferece essa extenso, e no foi possvel test-la. O RTO mnimo pode ser regulado no LKSCTP, porm das duas tentativas de resolver o problema por esse caminho, apenas uma foi bem-sucedida, apesar do cenrio de teste ser rigorosamente o mesmo. Na tentativa bem-sucedida, a latncia descia a patamares semelhantes ao TCP, mas na tentativa frustrada, a associao acabava estolando aps um certo volume trafegado. Mais testes so necessrios para vericar se o controle de congestionamento do SCTP tem alguma instabilidade associado a perdas constantes de pacotes de rede. De qualquer forma, com ou sem instabilidade, o RTO mnimo padro de 1 segundo, apesar de estar em conformidade com a RFC 2960, excessivo para uso no mundo real. 5.7.4. Rede 10Mbps com latncia Na ausncia de perdas, a vazo de um protocolo conrmado deveria ser independente da latncia da rede. Mas a gura 5.8 evidencia o contrrio, tanto para TCP quanto para SCTP. A razo que o aplicativo construdo para o teste usa buffers de recepo

62

Tabela 5.8: Vazo em kbps, rede 10Mbps com latncia de rede

Protocolo / latncia de rede TCPM SCTP 5ms 3966 3366 30ms 2900 2074 100ms 2326 1570 300ms 782 882

Figura 5.9: Latncia de transao, rede 10Mbps com latncia de rede

Latencia rede 10Mbps com latencia 700000

600000 "sctp" "tcpm"

500000 microssegundos

400000

300000

200000

100000

0 0 50 100 150 200 latencia da rede (milissegundos) 250 300

no tamanho default do sistema operacional. Para obter performance tima, esses buffers devem ser maiores que o produto latncia de rede largura de banda. Os testes utilizaram sempre o tamanho padro, pois o que faz a maioria das aplicaes na prtica. E mesmo quando a aplicao permite a regulagem do buffer, dicilmente algum usurio atua sobre esse parmetro. Confome mostram a tabela 5.8 e a gura 5.8, a performance de vazo do SCTP foi congruente com os demais testes (menor que TCP), considerando-se o tamanho da mensagem de 500 bytes. O desempenho do SCTP foi melhor que TCP quando o RTT de rede atingiu valores muito altos (600ms). Mas RTTs dessa ordem de grandeza so raros mesmo na Internet, sendo observados apenas em comunicaes via satlite. Conforme mostram a tabela 5.9 e a gura 5.9, a latncia mdia da transao foi essencialmente o RTT da rede. A latncia adicional do SCTP, demonstrada em outros

63

Tabela 5.9: Latncia de transao em s, rede 10Mbps com latncia de rede

Protocolo / latncia de rede TCPM SCTP 5ms 10303,5 10355,0 30ms 60286,0 60337,0 100ms 200266,0 200298,5 300ms 600183,5 600189,5

Figura 5.10: Vazo, rede 10Mbps com latncia de rede e perda de pacotes
Vazao rede 10Mbps com latencia e perda de 1% 4000 3500 3000 2500 kbps 2000 1500 1000 500 0 0 50 100 150 200 latencia da rede (milissegundos) 250 300 "tcpm" "sctp"

testes, aqui ca totalmente diluda. 5.7.5. 10Mbps com latncia e perda de pacotes Quanto vazo, a gura 5.10 e a tabela 5.10 mostram valores congruentes com outros testes. O SCTP tende a estreitar a diferena com TCP na medida que a latncia da rede alcana valores muito altos, devido ao RTO mnimo padro ser de 1 segundo. A latncia, conforme o sucedido em outros testes, foi prejudicada na presena de perda constante. Mas a gura 5.11 e a tabela 5.11 mostram que, quanto maior a latncia, Tabela 5.10: Vazo em kbps, rede 10Mbps com latncia de rede e perda de pacotes
Protocolo / latncia de rede TCPM SCTP 5ms 3758 2760 30ms 1520 1068 100ms 522 408 300ms 152 132

64

Figura 5.11: Latncia de transao, rede 10Mbps com latncia de rede e perda de pacotes
Latencia rede 10Mbps com latencia e perda de 1% 700000

600000 "sctp" "tcpm"

500000 microssegundos

400000

300000

200000

100000

0 0 50 100 150 200 latencia da rede (milissegundos) 250 300

Tabela 5.11: Latncia de transao em s, rede 10Mbps com latncia de rede e perda de pacotes
Protocolo / latncia de rede TCPM SCTP 5ms 17006,5 34844,5 30ms 66986,0 79712,5 100ms 219057,5 239280,5 300ms 619908,5 624185,0

65

Tabela 5.12: Vazo e latncia de transao, rede 1Mbps com de latncia de rede e duplicao de pacotes Protocolo Vazo (kbps) Latncia (s)
TCPM SCTP 710 652 100204,25 108955,25

Tabela 5.13: Vazo e latncia de transao, rede 1Mbps com latncia de rede, perda e duplicao de pacotes Protocolo Vazo (kbps) Latncia (s)
TCPM SCTP 740 682 105480,3 109036,0

mais bem adaptado ca o SCTP. A razo que o RTT foi se aproximando do RTO mnimo padro (1 segundo). 5.7.6. Rede 1Mbps, latncia e duplicao de pacotes

A vazo do SCTP, pouco menor que TCP, conforme a tabela 5.12, foi congruente com os demais testes. A latncia do SCTP cou sensivelmente mais alta que o RTT da rede, devido ao RTO mnimo padro (1 segundo, 10 vezes maior que o RTT mdio de 100ms). 5.7.7. Rede 1Mbps, latncia, duplicao e perda de pacotes

A tabela 5.13, que contm os resultados deste teste, mostra uma aparente inconsistncia: as vazes foram maiores na presena da perda constante, do que no teste de 1Mbps sem perda constante (tabela 5.12). Tal diferena pode ser explicada pela inuncia desprezvel da pequena perda constante sobre a vazo (pois a maior parte das perdas varivel e provocada pela simulao de congestionamento), e pela varincia natural do teste. A perda constante inuenciou negativamente a latncia do TCP. Interessante notar que a latncia do SCTP cou praticamente inalterada. 5.7.8. Rede 11Mbps wireless

O desempenho do SCTP, um pouco menor que o do TCP, foi congruente com os demais testes realizados, conforme mostra a tabela 5.14.

66

Tabela 5.14: Vazo e latncia, rede 11Mbps wireless Protocolo Vazo (kbps) Latncia (s)
TCPM SCTP 1221 916 6392,5 7829,0

Tabela 5.15: Vazo e latncia, rede 100Mbps um servidor e dois clientes Simultneo Cliente Protocolo Vazo (kbps) Latncia (s)
No SOLDIER COP Sim SOLDIER COP TCPM SCTP TCPM SCTP TCPM SCTP TCPM SCTP 16584 15520 (*) 9176 15448 4816 7736 4792 7784 421 516 425 523 490 681 490 681

5.7.9. Dois clientes 100Mbps

O servidor consideravelmente mais fraco que qualquer dos clientes, portanto os resultados sero diferentes de testes anteriores com 100Mbps. Para ter-se uma base de comparao, os testes foram refeitos entre cada cliente individual e o servidor. Os resultados do teste esto na tabela 5.15. Para a vazo, o resultado ideal seria que a vazo total fosse a mesma para 1, 2 ou mais clientes. Foi o que aconteceu com SCTP. J o TCP experimentou uma perda ao atender 2 clientes simultaneamente. A razo no exatamente um problema do TCP, e sim que os uxos nas 2 direes caram descompassados (i.e. o trfego num sentido acabava muito antes que o outro), baixando a mdia. Isso foi causado pela combinao servidor lento e cliente rpido. O SCTP tambm experimentou vazes baixas em outros testes pelo mesmo motivo. Mas por algum motivo o SCTP conseguiu, neste teste, manter o uxo equilibrado em ambos os sentidos. A tabela 5.15 ainda tem um ponto marcado com asterisco, assinalando um caso que o teste com TCP sofreu descompasso mesmo sem simultaneidade de clientes. Nas latncias de transao, as latncias do TCP foram todas mais baixas, como de costume; e o TCP sofreu menos o efeito da simultaneidade (15%) que o SCTP (30%). A possvel razo o consumo de CPU inerentemente maior do SCTP (checksum CRC-32c) associado a um servidor fraco e ocupado.

67

Tabela 5.16: Vazo em kbps, conexes multicaminhos 10Mbps e 11Mbps

Protocolo TCPM SCTP Rede 10Mbps 3746,0 2586,0 Rede 11Mbps 1786,0 1128,5 Ambas (multicaminhos) (*) 1064,0 1750,0

Tabela 5.17: Latncia em s, conexes multicaminhos 10Mbps e 11Mbps

Protocolo TCPM SCTP Rede 10Mbps 1773,5 1886,0 Rede 11Mbps 5757,5 6868,5 Ambas (multicaminhos) (*) 4319,0 4505,5

5.7.10. Multicaminhos 10Mbps e 11Mbps A associao SCTP feita enquanto o link primrio est ativo, pois a implementao LKSCTP no possui a funo sctp_connectx() que permitiria especicar diversos endereos de servidor. A descoberta dos endereos secundrios do servidor feita automaticamente na criao da associao (que s pode acontecer quando o link primrio est ativo). Em TCP no teste com multicaminhos, ele simplesmente usa o link primrio, e o trafego cessa nos perodos de bloqueio. Naturalmente, a performance ser sofrvel nessa situao. Seria difcil tornar esse teste mais justo para o TCP, j que TCP no tem nenhum recurso semelhante a multicaminhos. Os principais objetivos do teste so determinar se o multicaminhos do LKSCTP funciona, e se ele reage sucientemente rpido para funcionar sobre uma rede problemtica. O parmetro ajustvel path_max_retrans do SCTP foi calibrado para 1 (o valor padro 5), mais apropriado para a rede do teste, pois o tempo de retransmisso cresce exponencialmente. Numa rede normal, onde as falhas sejam infreqentes, o valor original pode ser adequado. Os resultados dos testes de vazo esto listados na tabela 5.16. Como naturalmente esperado, a vazo do SCTP com multicaminhos foi muito superior ao do TCP, cando na mdia entre os links individuais. A tabela 5.16 tambm lista a vazo de cada caminho isolado, para vericar a congruncia com os demais testes.

Quanto a latncia. Apesar do uso de multicaminhos, a tabela 5.17 mostra que o desempenho do SCTP foi quase igual ao TCP. Vericou-se atravs de ferramentas de

68

diagnstico de rede que o SCTP continuou usando o caminho secundrio (cuja latncia muito maior) por 2 ou 3 segundos mesmo depois do caminho primrio voltar a funcionar. Para efeitos de comparao, o RTT da rede 10Mbps do teste era aproximadamente 0.36ms, e o RTT da rede 11Mbps era de aproximadamente 2.75ms. Os valores foram obtidos atravs do utilitrio ping. 5.8. Validade dos testes Os testes, na verdade, no avaliaram os protocolos TCP e SCTP em si, mas sim duas implementaes particulares desses protocolos. Ainda assim, considera-se que os testes fornecem subsdios para a avaliao dos protocolos, pelas seguintes razes: demonstram que as promessas do protocolo SCTP podem ser entregues na prtica; as duas implementaes compartilham muitas caractersticas de implementao (estruturas de kernel, camada de rede etc.), de modo que as maiores diferenas observadas devero ser a priori explicveis por diferenas entre os protocolos, e no entre as implementaes; a maturidade do TCP no Linux, pelo tempo de desenvolvimento e uso generalizado, fornece razovel certeza de que o desempenho do TCP um patamar dicilmente supervel por outros protocolos conrmados e/ou por outros sistemas operacionais, dado o mesmo hardware; a relativa imaturidade do LKSCTP sugere que a performance obtida nos testes deste trabalho atingvel por qualquer outra implementao razovel (em particular se kernel-level) e o LKSCTP tende a melhorar com o tempo (ou pelo menos, no piorar); os parmetros ajustveis do protocolo, como RTO mnimo, foram deixados intocados tanto quanto possvel. Em alguns casos isolados foi necessrio manipul-los para determinar se um problema era causado pelo protocolo ou por uma falha da implementao. Tais ocorrncias esto devidamente documentadas. 5.9. Concluses Os testes evidenciam que o desempenho do SCTP prximo e inferior ao TCP, um resultado esperado pelas caractersticas inerentes a cada um. Em algumas situaes o SCTP teve desempenho melhor que TCP, mas foram situaes-limite (RTT alto, percentagem especca de perda de pacotes) que no autorizam a dizer que o SCTP possa ter performance sustentada maior que TCP em uma rede real.

69

Uma fonte importante de sobrecarga do SCTP a separao de mensagens. A maioria dos testes TCP utilizou um protocolo de aplicao, denominado TCPM, criado especialmente para os ns deste captulo. Sua nica funo impor a sobrecarga de separao de mensagens ao TCP, permitindo uma comparao mais justa de desempenho entre os dois protocolos de transporte. Foram encontradas duas falhas algo graves do LKSCTP: o RTO (timeout de pacote perdido) mnimo padro congurado para 1 segundo (muito alto), e o algoritmo de controle de congestionamento que pode ter alguma instabilidade relacionada perda constante de pacotes. Para tornar-se um protocolo de uso generalizado, o SCTP dever absorver as melhorias recentes no controle de congestionamento que o TCP demonstrou possuir.

6. Comparao de desempenho com TCP e UDP em aplicaes reais

6.1. Objetivos Os testes deste capitulo objetivam vericar a performance do SCTP com protocolos de aplicao reais, usando implementaes reais. A escolha dos protocolos de aplicao levou em conta os seguintes critrios: relevncia do protocolo na Internet, potencial de melhoria de performance no uso de SCTP como transporte, e existncia de implementaes de livre distribuio facilmente adaptveis. O protocolo HTTP , de longe, a primeira escolha em todos os critrios. Praticamente todo texto introdutrio sobre SCTP, como ARIAS-RODRIGUEZ, menciona o HTTP como candidato a adaptao. O mtodo de teste ser a transmisso de objetos de tamanho xo via HTTP, e o critrio de avaliao do desempenho a vazo em KBytes/s (que indiretamente indica o nmero de objetos transmitidos por unidade de tempo). Dentre inmeros protocolos cliente/servidor com mensagens de tamanho limitado, que tirariam proveito das mensagens indvisveis do SCTP, o protocolo SMB (tambm conhecido pelos nomes NetBIOS e CIFS) foi escolhido por possuir implementaes fora do kernel. A primeira escolha teria sido o NFS, mas tanto cliente quanto servidor NFS so tipicamente implementados dentro do kernel, o que torna a adaptao muito mais difcil de testar e depurar. Assim como o HTTP, o SMB tambm usa originalmente o TCP como transporte. Dois mtodos de teste sero empregados. O primeiro mtodo mede a vazo mediante a transmisso de um nico arquivo grande, assemelhando-se experincia de um usurio copiando um arquivo ou pasta atravs da rede. O segundo mtodo estima a latncia, executando-se um grande nmero de operaes de arquivo pequenas e serializadas, de forma semelhante a um banco de dados cujo arquivo est num servidor de rede. Era desejvel que este captulo abordasse ao menos um protocolo de aplicao baseado em UDP. Para atender a esse objetivo, foi escolhido o protocolo RTP, que alm de tudo proporciona uma excelente oportunidade de testar a extenso PRSCTP, at aqui no abordada em nenhum teste. O mtodo de teste do RTP medir a capacidade de entregar com qualidade aceitvel um contedo multimdia udio em formato MP3 atravs de uma rede com banda estreita e perdas de pacotes.

71

O protocolo FTP foi cogitado como quarta opo, mas foi descartado pois sua adaptao ao SCTP exigiria extenses ao protocolo de aplicao para aproveitar os mltiplos uxos, sem nenhuma perspectiva de uso prtico. O FTP um protocolo obsoleto; HTTP (em particular com a extenso WebDAV) e SFTP so alternativas melhores e prontamente disponveis. 6.2. Adaptao dos protocolos de aplicao ao SCTP O SCTP facilita a adaptao dos protocolos de aplicao originalmente concebidos para outros transportes. Em geral, nenhuma alterao no protocolo de aplicao em si necessria. o caso das adaptaes do SMB e do RTP. Mas, para aproveitar melhor as novas caractersticas do SCTP, uma adaptao mais profunda, com alguma modicao no protocolo de aplicao, se faz necessria. o caso da adaptao do HTTP. Apesar de tudo, a adaptao proposta neste trabalho causa baixo impacto na denio do protocolo, e conseqentemente baixo impacto nas implementaes. As adaptaes aqui sugeridas podem ainda ser objeto de estudo mais aprofundado e/ou serem propostas ao IETF. 6.2.1. HTTP A adaptao do HTTP ao SCTP procurou atingir os objetivos delineados em com o menor impacto possvel sobre o protocolo denido na RFC 2616 (FIELDING, R. et al.). Adaptao nvel 1 simples substituio de TCP por SCTP: Nenhuma alterao no protocolo trafegado, o que possibilita usar o mesmo interpretador HTTP sobre TCP e sobre SCTP; Associao SCTP com apenas um par de uxos, um em cada direo, o suciente para emular uma conexo TCP; Os dados tm de ser tratados como um uxo contnuo, ignorando a atomicidade de mensagens proporcionada pelo SCTP; Clientes tm de solicitar associaes com exatamente um par de uxos, e servidores tm de criar a associao tambm com exatamente um uxo por direo. Isso sinaliza de parte a parte que a implementao nvel 1; O cliente HTTP no pode tentar colocar a associao em estado meio-fechado (atravs de shutdown() ou API equivalente) para sinalizar m de requisio HTTP, pois o SCTP no suporta o estado meio-fechado.

72

Adaptao nvel 2 uso de mltiplos uxos SCTP:

Nenhuma alterao no protocolo trafegado, o que possibilita usar o mesmo interpretador HTTP sobre TCP e sobre SCTP; Os dados tm de ser tratados como um uxo contnuo, ignorando a atomicidade de mensagens proporcionada pelo SCTP; O cliente HTTP no pode tentar colocar a associao em estado meio-fechado (atravs de shutdown() ou API equivalente) para sinalizar m de requisio HTTP, pois o SCTP no suporta o estado meio-fechado; Os uxos SCTP de mesmo nmero e direes opostas so agrupados em pares. Cada par tratado como uma conexo bidirecional isolada das demais, tal qual TCP. A requisio HTTP transmitida pelo uxo de nmero n, respondida atravs do uxo de nmero n de sentido oposto. Isso facilita a implementao e vem ao encontro da RFC 3436 (JUNGMAIER et al, 2002, dene o protocolo de segurana TLS para SCTP) que agrupa os uxos da mesma forma; O cliente HTTP deve requisitar tantos pares de uxos quantos forem os arquivos que pretenda obter do servidor, at o limite do protocolo (65536) ou o limite imposto pela implementao SCTP; O servidor HTTP deve criar a associao com, no mximo, o nmero de uxos requisitado pelo cliente. facultado ao servidor criar a associao com menos uxos que o requisitado, se por qualquer motivo no puder atender o pedido original do cliente (muito provavelmente implementaes reais vo impor limites relativamente baixos, para minimizar o impacto de ataques de inundao); O cliente HTTP tem de adaptar-se graciosamente ao nmero de uxos realmente aceito pelo servidor (geralmente abrindo outra(s) associao(es) para requisitar os arquivos restantes); O servidor pode rejeitar como invlidas as associaes onde o cliente tenha requisitado um nmero diferente de uxos em cada direo. Se optar em aceitar a associao, deve considerar o menor dos dois nmeros de uxos como sendo o real nmero de conexes; O servidor HTTP no pode fechar a associao at que todos os uxos tenham feito as ltimas requisies (parmetro Connection:close), e todas essas requisies estejam satisfeitas. O parmetro Connection:close passa a indicar apenas que o par de uxos no pode ser mais usado para nenhuma requisio;

73

Todas as mensagens SCTP que compem a resposta HTTP devem ter o cdigo de protocolo igual a zero. Quando a transao HTTP for a ltima a acontecer em determinado uxo (Connection:close), a ltima mensagem SCTP da resposta deve ter o cdigo de protocolo diferente de zero; Mudana na seo 4.4 da RFC 2616, que dene as estratgias de identicao de m-de-arquivo bem como a prioridade de aplicao (mudana em negrito): 1. Mensagem de resposta sem corpo termina sempre e linha vazia; 2. Transferncia em trechos (chunked) auto-delimitada; 3. Valor do parmetro Content-Length; 4. Mdia codicada (e.g. comprimida por gzip) considerada auto-delimitada, se Content-Length no estiver presente; 5. Mensagem com cdigo de protocolo diferente de zero, quando a transao Connection:Close; 6. Fechamento da associao por parte do servidor indica m de arquivo para todos os uxos. O cliente HTTP deve dar preferncia ao uso de mltiplos uxos em lugar de pipelining.

Alocar um nmero arbitrariamente grande de uxos, mas utilizar apenas alguns deles, contemplaria o caso de o cliente no saber exatamente, no momento da associao, quantos arquivos pretende requisitar. Essa possibilidade foi vetada pelos seguintes motivos:

Consumiria muita memria de kernel por associao SCTP, em implementaes que no otimizassem esse perl de uso, como o caso do LKSCTP; O servidor HTTP tpico aloca uma estrutura de controle de conexo no momento que a conexo TCP criada. No caso do SCTP, todas as estruturas de conexo seriam criadas na criao da associao. Admitir que a maioria das conexes no seria usada implicaria em atrasar sua criao, complicando ainda mais o processo de adaptao; Na prtica, todo servidor HTTP sobre SCTP nvel 2 iria limitar o nmero de uxos em um nmero bastante baixo, para dicultar ataques de inundao e diminuir o consumo de memria, tanto no kernel quanto no aplicativo. Aceitar 65536 uxos signicaria criar at 65536 estruturas de controle de conexo para uma nica associao, facilitando o ataque de inundao.

74

6.2.2. SMB O protocolo SMB tambm conhecido pelas siglas CIFS e NetBIOS. o protocolo de compartilhamento de arquivos e impressoras nativo da famlia de sistemas operacionais Microsoft Windows. A denio original do protocolo est nas RFCs 1001 (AGGARWAL, 1987) e 1002 (AGGARWAL, 1987a). Desde sua criao em 1984, o SMB foi adotado e estendido por diversos fabricantes. Em geral, as extenses no foram formalizadas em RFCs ou livros. Alguns materiais como o de LEIGHTON tentam documentar as extenses conhecidas, mas o fato que a verso do SMB em uso corrente no tem um documento pblico que descreva-o de forma completa e exata. A implementao considerada ocial, por ser a mais utilizada, a do sistema operacional Microsoft Windows, com quem as demais implementaes tentam manter-se interoperveis lanando mo de engenharia reversa. A adaptao do SMB consiste simplesmente na substituio do TCP por SCTP. O protocolo em si no sofre nenhuma modicao. Cada mensagem SMB ser transmitida como uma mensagem indivisvel SCTP, o que em tese desonera o receptor da separao de mensagens. Os servios SMB baseados em UDP, como a resoluo de nomes, permanecem como esto, pois fazem uso de broadcast. 6.2.3. RTP O protocolo RTP denido pela RFC 1889 (SCHULZRINNE et al.). A adaptao para SCTP no exige nenhuma mudana no RTP em si. A implementao deve gerar mensagens indivisveis SCTP da mesma forma que geraria pacotes UDP. Se o RTP est sendo usado para transmisso em tempo real, as mensagens SCTP devem ter um prazo de validade nito provavelmente baseado nos RTT e RTO da associao, cujos valores so consultveis pelo aplicativo. O aplicativo tambm pode processar as noticaes sobre mensagens no transmitidas, e com base nisto calibrar o prazo de validade. (Usando UDP, a nica forma de obter feedback sobre perdas atravs do protocolo auxiliar RTCP.) A presena ou ausncia da extenso PRSCTP no altera em nada as aplicaes (nem mesmo exige recompilao), mas melhora a performance em caso de congestionamento severo da rede.

75

6.3. Aplicativos adaptados para os testes A metodologia de alterao dos programas foi, resumidamente, a seguinte:

Busca das chamadas socket() e mudana para SCTP; Vericao das chamadas setsockopt(), vericando quais devem ser mudadas para adequao ao SCTP, e quais simplesmente no cabem no SCTP; Busca de chamadas shutdown() que criem o estado meio-fechado, eliminao da chamada (se isto no afeta o protocolo de aplicao e h uma chamada close() mais adiante que feche a associao); Vericao do tamanho da mensagem e dos buffers de transmisso/recepo (os buffers tm de ser maiores que a maior mensagem a ser trafegada); Deciso de uso do estilo TCP ou UDP, de acordo com o mais adequado ao estilo de programao do aplicativo. Na grande maioria dos casos o soquete TCP ser mais adequado, pois a maioria dos programas adaptveis utilizava TCP.

Se a adaptao pretende usar vrios uxos em lugar de vrias conexes, alteraes mais profundas so necessrias. A principal identicar de que uxo veio determinada mensagem, pois o manipulador de arquivo deixa de ser um identicador unvoco para a conexo. Tipicamente ser inserido cdigo entre a leitura e o despacho da mensagem, de forma a entreg-la conexo correspondente. Tambm necessrio vericar quando uma conexo coloca o manipulador de arquivo em estado somente-leitura ou somente-gravao; ao fazer isso sobre uma associao SCTP, estar afetando outras conexes. Todas estas chamadas devero fazer testes adicionais (e.g. para colocar o soquete em estado somente-leitura, todas as conexes relacionadas devem estar nesse estado). 6.3.1. HTTP Do lado servidor, a implementao escolhida foi o thttpd verso 2.25b. Este servidor posiciona-se como uma alternativa mais simples de congurar e mais leve que o Apache. Sua principal caracterstica usar apenas um processo que atende a todas as requisies de pginas estticas, proporcionando grande performance. J pginas dinmicas provocam forosamente a criao de processos-lhos, no estilo CGI clssico; bibliotecas carregveis dinamicamente no so suportadas. Portanto, o thttpd no adequado para servidores de contedo majoritariamente dinmico.

76

Outra caracterstica do thttpd ser portvel apenas para sistemas POSIX, enquanto o Apache tambm suporta outras APIs como Windows 32 bits e Novell Netware. O thttpd tambm no implementa pipelining. O thttpd sofreu as adaptaes nvel 1 e 2 para SCTP. A adaptao nvel 2 foi consideravelmente mais trabalhosa e exigiu mais depurao. Cabe ressaltar que a arquitetura monoprocesso/monolinha facilitou a tarefa. O suporte a CGI foi desligado na adaptao nvel 2, pois o thttpd delega completamente o tratamento da conexo a um subprocesso, o que em SCTP no seria adequado, pois a cada soquete esto atreladas diversas conexes. Suportar CGI na adaptao nvel 2 exigiria mudar mais profundamente o funcionamento do servidor, sem qualquer benefcio para este trabalho. Os clientes HTTP adaptados foram o Mozilla verso 1.6 e o httperf verso 0.8. O Mozilla sofreu uma adaptao nvel 1. A adaptao nvel 2 exigiria um estudo profundo de seu funcionamento interno, o que fugiria ao escopo deste trabalho (o cdigofonte do Mozilla tem 300 MB), e de qualquer forma no serviria para testar objetivamente o servidor. O httperf um software especicamente criado para testar a performance de servidores HTTP. Ele cria conexes (ou associaes) na medida em que o servidor atende as anteriores, at chegar saturao do servidor. Este software sofreu adaptao nveis 1 e 2, de modo que o thttpd sobre SCTP pudesse ser testado de forma objetiva. Assim como o thttpd, a adaptao nvel 2 foi consideravelmente mais trabalhosa. Felizmente, o httperf tambm no multithreaded. 6.3.2. SMB O software escolhido para a adaptao foi o Samba verso 3.0.4, uma implementao de servidor SMB/CIFS para UNIX. O Samba tambm fornece utilitrios-clientes para SMB, como o smbclient que ser utilizado nos testes. A adaptao do Samba foi a mais simples dentre todos os softwares, por diversas razes. O protocolo de aplicao no precisou de qualquer adaptao. O cdigo-fonte do Samba bem organizado e a criao de soquetes est concentrada em algumas poucas funes de biblioteca. Os soquetes SCTP estilo TCP funcionaram perfeitamente no lugar dos soquetes TCP originais. O Samba no utiliza chamadas como shutdown() ou recursos como byte urgente que implicariam em mudanas mais trabalhosas. O separador de mensagens SMB poderia ter sido simplicado, pois em SCTP toda mensagem SMB ser atmica. Esta alterao no foi feita por ser custosa, diminuir a

77

robustez (algum cliente problemtico poderia mandar uma mensagem fragmentada), e no aplicar-se num Samba adaptado para TCP e SCTP simultaneamente (o separador continuaria atuando ao menos para os soquetes TCP). Ainda assim, as mensagens indivisveis SCTP poderiam trazer um ganho de perfomance ao SMB, pois o processo ser acordado apenas quando for receber e processar uma mensagem SMB completa. Foi necessrio congurar os buffers de transmisso e recepo para valores acima de 64KBytes, pois este o tamanho mximo de uma mensagem SMB, e o SCTP retorna erro para mensagens maiores que o buffer de transmisso. Isso pde ser resolvido no arquivo de congurao, sem demandar mais mudanas no software em si. Uma adaptao mais robusta teria de vericar se os buffers tm o tamanho mnimo exigido. 6.3.3. RTP O software poc verso 0.3.7 implementa clientes e servidores RTP para transferncia de udio no formato MP3. (Este software no implementa RTCP). Apesar de suportar bitrate xo e dividir a informao em quadros de tamanho xo, o MP3 no foi projetado para transmisso com perdas. Um quadro pode referenciar dados de quadros anteriores; os quadros com sons mais simples emprestam o espao livre para quadros futuros com sons mais complexos. Esse mecanismo, conhecido como reservoir, permite oferecer uma qualidade sonora razovel com um bitrate baixo e constante. Mas os quadros deixam de ser stateless, o que desqualica o MP3 para aplicaes de tempo real como telefonia sobre IP. Tambm amplica o efeito da perda de um pacote sobre a qualidade de udio. Para amenizar esse problema, o poc implementa trs alternativas de mitigao de perdas para MP3: RFC 2250 (HOFFMAN et al.), RFC 3119 (FINLAYSON), e Forward Error Correction FEC. Este o nico software dentre os adaptados que usa o soquete estilo UDP para transmisso de dados, pois neste o estilo UDP diminuiu o impacto da adaptao. 6.3.4. Outros aplicativos Os softwares trafshow e telnet foram tambm adaptados para SCTP, como ferramentas de depurao de rede.

78

Figura 6.1: Vazo HTTP, rede de 100Mbps

Vazao HTTP 100Mbps 12000 "tcp" "sctp-1" "sctp-10" "sctp-100"

10000

8000 kBytes/s

6000

4000

2000

0 100

1000 Tamanho arquivo

10000

100000

6.4. Resultados 6.4.1. HTTP Dois cenrios foram criados para os testes HTTP: rede 100Mbps Ethernet; rede 1Mbps simulada (perde pacotes na saturao), sem perdas constantes, latncia de 30ms, duplicao de 0,1%. Os testes utilizaram as adaptaes nvel 2 para SCTP, que so capazes de utilizar vrios uxos por associao. A performance das adaptaes nvel 1 seria equivalente s adaptaes nivel 2, desde que utilizando apenas um uxo por associao. Nesses testes, a quantidade de arquivos tranferidos pelo httperf foi calibrada de forma a no saturar o servidor, pois o objetivo era medir a vazo e no o nmero mximo de conexes possveis (que dependem unicamente de conguraes e/ou variveis de compilao do thttpd). No cenrio de rede 100Mbps, os resultados podem ser vistos na gura 6.1 e tabela 6.1. Para apenas um uxo, a performance do SCTP menor que TCP, como em todos os testes de vazo bruta que j foram feitos.

79

Tabela 6.1: Vazo HTTP em Kbytes/s, rede de 100Mbps

Tamanho arquivo (bytes) 100 1000 10000 100000 TCP 1008,7 2315,0 7688,2 10693,3 SCTP - 1 uxo 537,6 1458,6 5613,4 10226,1 SCTP - 10 uxos 1243,9 4043,1 6397,2 8880,5 SCTP - 100 uxos 2221,3 6281,7 9954,1 11314,1

Figura 6.2: Vazo HTTP, rede de 1Mbps com perdas e latncia

Vazao HTTP 1Mbps perda 1% latencia 30ms duplicacao 0.1% 120

100

80 kBytes/s

60

40 "tcp" "sctp-1" "sctp-10" "sctp-100"

20

0 100

1000 10000 Tamanho do arquivo transmitido

100000

Ainda, na medida em que os arquivos aumentam de tamanho, a vantagem do SCTP diminui at desaparecer, pois a vazo bruta da rede torna-se o limitador principal, e nesse caso o SCTP leva sempre desvantagem com sua maior sobrecarga. Um fator adicional detectado nesse teste, que prejudica os nmeros nais do SCTP, que a associao SCTP leva mais tempo que TCP para fechar a associao, tempo este que o httperf inclui no cmputo da vazo. J com o uso de vrios uxos por associao, a performance do SCTP foi melhor que TCP, em particular para arquivos pequenos. Este um resultado esperado, pois a sobrecarga da criao e destruio de conexes grandemente diluda, e o cliente pode requistar muito mais arquivos sem saturar o servidor (e a si mesmo). Os resultados do cenrio de rede 1Mbps, vericveis na gura 6.2 e na tabela 6.2, so congruentes com aqueles obtidos nos testes com a rede 100Mbps. A diferena a favor

80

Tabela 6.2: Vazo HTTP, rede de 1Mbps com perdas e latncia

Tamanho arquivo (bytes) 100 1000 10000 100000 TCP 3,3 10,7 56,4 117,7 SCTP - 1 uxo 2,2 7,2 33,9 95,3 SCTP - 10 uxos 39,4 61,7 73,6 110,4 SCTP - 100 uxos 88,9 100,2 115,3 108,0

do SCTP aumenta ainda mais pois a perda de um pacote atrasa a entrega de apenas um uxo, e no de todos. Alm deste trabalho, outros j testaram o HTTP sobre SCTP. Em particular o artigo de RAJAMANI et al. descreve um teste com HTTP sobre SCTP, e chegou a resultados anlogos aos deste trabalho, embora tenha usado o sistema operacional BSD com uma implementao KAME relativamente imatura (o artigo datado de 2002, e o KAME SCTP tinha ento apenas sete meses de existncia). O servidor HTTP no especicado no artigo. O mtodo de teste foi essencialmente o mesmo transmitir um certo nmero de arquivos de tamanho xo. Mas a mtrica utilizada para quanticar o desempenho naquele artigo foi a latncia, ou seja, o tempo mdio de entrega de um arquivo, ao invs da vazo. 6.4.2. SMB Dois cenrios bsicos foram criados para os testes HTTP e SMB:

rede 100Mbps Ethernet; rede 1Mbps simulada (perde pacotes na saturao), sem perdas constantes, latncia de 30ms, duplicao de 0,1%.

Em 100Mbps, o teste de vazo consistiu da transmisso de um arquivo de 100 milhes de bytes. J em 1Mbps, foi transmitido um arquivo de 1 milho de bytes. Foram utilizados arquivos diferentes para que o teste no se alongasse demasiadamente em 1Mbps. O teste de latncia consistiu da execuo repetida de dois comandos: transmisso de um arquivo de 100 bytes, e imediata remoo desse arquivo. O objetivo do teste medir a agilidade no processamento de vrias transaes pequenas, comuns aplicaes. Para 100Mbps, o par de comandos foi repetido 5000 vezes. Em 1Mbps, o par foi repetido 100 vezes.

81

Tabela 6.3: Vazo e latncia SMB (valores em segundos, vide seo 6.4.2)
Rede / teste 100Mbps 1Mbps TCP - vazo 11,54 8,53 SCTP - vazo 12,39 11,51 TCP - latncia 6,12 30,02 SCTP - latncia 7,13 30,09

Todos os valores dos testes, listados na tabela 6.3, so em segundos corridos (wall clock). Valores menores equivalem a melhor desempenho. O SCTP foi superado pelo TCP em todos os testes. A simples substituio de TCP por SCTP no trouxe ganho de performance. O principal motivo parece ser o fato da implementao emitir duas mensagens para cada requisio, o que aumenta a desvantagem do SCTP pois as duas mensagens so entregues rigorosamente separadas no destino. Seria necessria uma adaptao mais profunda, que explore melhor a separao de mensagens do SCTP, emitindo apenas uma mensagem por requisio e desligando a separao de mensagens na camada de aplicao, que o SCTP supre. 6.4.3. RTP O teste de performance do RTP no mede a latncia ou vazo, mas sim a capacidade de entregar satisfatoriamente um contedo multimdia atravs de uma rede com perdas. O contedo consiste de udio MP3 com taxa contnua (CBR) de 192kbps. O critrio de entrega satisfatria subjetivo, pois avaliado com base na sada de udio por um ouvinte humano (o prprio autor). Foi utilizada uma grade de cenrios, com larguras de banda entre 200kbps e 300kbps em passos de 10kbps, e taxas de perda de pacotes de 0%, 0,1%, 0,2%, 0,5%, 1%, 2%, 5% e 10%. A latncia de rede simulada xa em 30ms (RTT=60ms). O prebuffering no cliente foi de 200ms, exceto no protocolo FEC onde o prebuffering xo e no pode ser dimensionado em termos de tempo. O consumo de banda do contedo foi em torno de 205kbps para RFC 2250 e RFC 3119, e 260kbps para FEC. As mensagens SCTP foram remetidas sem garantia de reordenamento e com prazo de validade padro de 200ms. Houve situaes que exigiram a mudana desse prazo de validade. No SCTP padro, a mensagem vencida descartada somente se sua transmisso ainda no foi tentada. Com a extenso PRSCTP, a mensagem vencida descartada mesmo se j transmitida; o receptor instrudo a avanar a janela TSN sem esperar pelas mensagens perdidas.

82

Figura 6.3: Desempenho RFC 2250 sobre UDP, SCTP e PRSCTP

MP3 sobre RTP - RFC 2250 Acima e a esquerda da linha = qualidade aceitavel 300

280

260 kbps 240 220

"udp" "sctp" "pr-sctp" 0.1 1 % perda pacotes 10

200

Como o buffer do receptor pequeno, a correta estimativa do RTO (timeout de pacote) torna-se muito importante para o SCTP reagir rapidamente aos erros. O RTO mnimo padro do SCTP (rto_min), 1 segundo, seria totalmente inadequado para transporte de contedo multimdia em tempo real, de modo que este valor foi reduzido para 1 milissegundo. O RTO inicial (rto_initial) foi setado em 65ms, pouco mais que os 60ms do RTT da rede simulada. Assim, o SCTP adapta-se rapidamente rede sem ser mais agressivo do que seria o TCP na mesma situao. Os grcos 6.3, 6.4 e 6.5 indicam a linha divisria entre cenrios bem-sucedidos e mal-sucedidos. Os pontos mais acima e esquerda das linhas representam cenrios mais favorveis (mais banda, menos perda), onde o contedo multimdia passou bem. Os pontos abaixo e direita das linhas representam cenrios piores, onde o contedo no conseguiu passar. RFC 2250 O protocolo RFC 2250 muito sensvel a qualquer perda de pacotes, e foi includo neste teste apenas por completeza, para apreciar o desempenho do SCTP. O desempenho de cada transporte pode ser vericado na gura 6.3. Em UDP, qualquer falha faz o contedo apresentar rudo peridico da falha em diante, e dicilmente h recuperao. Com o SCTP, que adiciona conabilidade ao trfego,

83

Figura 6.4: Desempenho RFC 3119 sobre UDP, SCTP e PRSCTP

MP3 sobre RTP - RFC 3119 Acima e a esquerda da linha = qualidade aceitavel 300

280

260 kbps 240 220

"udp" "sctp" "pr-sctp" 0.1 1 % perda pacotes 10

200

o desempenho sob variadas perdas melhorou muito, viabilizando o RFC 2250. Alm disso, as falhas conseguem recuperar-se os rudos peridicos tendem a desaparecer pouco depois da falha. O SCTP normal apresentou desempenho mais linear, ou seja, aumentou a resistncia a falhas conforme havia largura de banda de sobra, enquanto o PRSCTP foi mais sensvel perda que largura de banda, e no funcionou com perdas superiores a 2%. RFC 3119 O protocolo RFC 3119 torna o contedo mais resistente a perdas, e evita o aparecimento de falhas peridicas na sada de som por conta de falhas isoladas. Seu comportamento foi muito bom tanto em UDP como em SCTP. Naturalmente, a resistncia a perdas foi muito maior com SCTP. Conforme mostra a gura 6.4, o PRSCTP foi mais eciente em situaes de largura de banda estreita e perdas moderadas, porm foi mais sensvel que o SCTP normal a situaes de perda severa (5% e acima), mesmo com grande sobra de largura de banda. Essa sensibilidade poderia ser melhorada com a reduo do prazo de validade das mensagens para um valor mais prximo do RTT.

84

Figura 6.5: Desempenho do protocolo FEC sobre UDP, SCTP e PRSCTP

MP3 sobre RTP - Forward Error Correction Acima e a esquerda da linha = qualidade aceitavel 300

280

260 kbps 240 220

"udp" "sctp" "pr-sctp" 0.1 1 % perda pacotes 10

200

FEC Forward Error Correction A gura 6.5 evidencia os resultados. Como o protocolo FEC gera dados redundantes, a largura de banda mnima para trfego 260kbps. Desta forma, o SCTP padro no funciona com largura de banda abaixo de 270kbps, pois um protocolo conrmado. O UDP conseguiu funcionar com taxas to baixas quanto 210kbps, pois o FEC encarrega-se de reparar a maioria dos erros no receptor, e sem reetir os erros na sada de udio. O PR-SCTP teve, por sua vez, um desempenho bastante interessante, cobrindo praticamente as mesmas situaes dos outros dois protocolos, e ainda apresentando desempenho superior que os demais em cenrios de banda escassa e perda moderada. O descarte de mensagens vencidas do PRSCTP conseguiu manter o uxo mesmo quando a banda da rede era inferior taxa de dados gerada pelo transmissor. Assim como no UDP, as perdas so reconstrudas no receptor graas ao FEC. Uma situao que exigiu ajuste do prazo de validade foi o SCTP e PRSCTP com perdas de 5% e superiores. O tempo de validade teve de ser calibrado para abaixo de 100ms, do contrrio o uxo de mensagens estolava completamente. Numa aplicao real, o prazo de validade teria de ser adaptativamente calibrado pelo transmissor, em funo do RTT e das noticaes de mensagens no transmitidas

85

por vencimento. Isto no um defeito do SCTP frente ao UDP, e sim uma conseqncia de ele ser conrmado e possuir controle de congestionamento. O receptor FEC ainda tem de sofrer ajustes para funcionar melhor com soquetes SCTP, pois ocorreram algumas falhas de audio no relacionadas a qualquer perda de dados (o prprio cdigo-fonte alerta que soquetes no bloqueantes devero ser empregados numa prxima verso).

7. Concluses e trabalhos futuros

O objetivo do trabalho foi demonstrar a viabilidade do uso do protocolo de transporte SCTP em lugar de outros protocolos de transporte (principalmente TCP). Procurouse fazer essa demonstrao de forma gradativa, dos aspectos histricos aos testes reais. Inicialmente foi demonstrada a necessidade da criao de um novo protocolo de transporte para a pilha TCP/IP, em funo da inteno de us-la em sinalizao telefnica. Para esta demonstrao, foi necessrio introduzir conceitos de outra pilha de rede, a SS7, utilizada em telefonia. Conforme mostrado, nenhum protocolo preexistente na pilha TCP/IP era adequado ao transporte de mensagens de sinalizao telefnica. O SCTP nasceu para esse m, inicialmente como um protocolo de aplicao denominado MDTP, e posteriormente realocado para a camada de transporte recebendo o nome atual. A seguir foram mostrados os novos recursos do SCTP em relao a TCP e UDP, com destaque para a atomicidade de mensagens, vrios uxos por associao, multicaminhos, extensibilidade e conabilidade parcial. At este ponto, o trabalho versou sobre assuntos j abordados por outros documentos citados na bibliograa, com as devidas atualizaes pois o protocolo SCTP ainda est em evoluo. Concluiu-se, como nos demais trabalhos, que o SCTP fornece diversos recursos novos e interessantes para os protocolos de aplicao, e que o SCTP uma novidade bem-vinda tambm para as redes TCP/IP de uso geral, como a Internet. A seguir, estudou-se que tipos de protocolos de aplicao poderiam ter vantagens reais se portados para o SCTP. Dentre os protocolos TCP, aqueles que fazem uso de mensagens atmicas de tamanho mximo bem denido podem beneciar-se do SCTP. Protocolos com mensagens arbitrariamente grandes, ou sem qualquer separao de mensagens, no aproveitam a atomicidade de mensagens do novo protocolo. Outros protocolos baseados em TCP que, independentemente do tipo de mensagem, poderiam aproveitar o SCTP, so aqueles onde diversas conexes de transporte so utilizadas para realizar uma nica transao lgica; tais conexes podem ser agrupadas numa nica associao. O exemplo clssico a busca de uma pgina HTTP completa com corpo e imagens. Dentre os protocolos de aplicao baseados em UDP, cujo uso cada vez mais reduzido, tambm so reduzidas as possibilidades de aproveitamento do SCTP. O UDP delega o controle das conexes lgicas aplicao, possibilitando suporte a milhes de

87

clientes simultneos (como nos servidores DNS globais) sem grandes problemas e com pouco overhead. O SCTP tambm no oferece suporte a multicast e broadcast. Um dos poucos usos provveis para SCTP em lugar de UDP no transporte de contedo multimdia, graas aos recursos de conabilidade parcial do SCTP (mensagens desordenadas e com prazo de validade). O SCTP tambm permite a presena simultnea de mensagens totalmente e parcialmente conveis na mesma associao, o que permite contedo e controle urem por um nico canal (e.g. RTP e RTCP). Trs protocolos de aplicao, bem como implementaes reais dos mesmos, foram adaptados para SCTP: HTTP, SMB e RTP. A adaptao proposta ao HTTP foi a mais elaborada pois previu o uso de diversos uxos numa mesma associao, ou seja, diversas conexes HTTP uindo por uma nica associao SCTP. Nenhuma das trs adaptaes implicou em mudanas no protocolo de aplicao em si. Foram realizados testes com a implementao LKSCTP (Linux Kernel SCTP), a mais avanada dentre as implementaes SCTP de cdigo-fonte aberto, suportando muitas extenses como PRSCTP e AddIP. Foram medidas vazo e latncia em variados cenrios de rede. Os resultados foram em geral os esperados: o SCTP tem performance comparvel, embora sempre um pouco menor, que TCP, devido ao maior overhead nos dados e no consumo de CPU. Duas decincias srias na implementao do algoritmo de congestionamento do SCTP foram detectadas; os resultados sero devidamente repassados aos mantenedores do LKSCTP. Os programas utilizados nos testes de latncia e vazo foram construdos especialmente para a tarefa, e no executam praticamente nenhum processamento, para evidenciar apenas as caractersticas dos protocolos de transporte. Uma medida de justia entre SCTP e TCP foi impor a separao de mensagens na camada de aplicao para TCP, pois o SCTP sempre entrega mensagens atomicamente. Mas pelo menos dois grupos de testes, em rede loopback e Fast Ethernet, tambm foram feitos com TCP sem separao de mensagens, para que todas as possibilidades fossem contempladas. Finalmente, as implementaes dos protocolos HTTP, SMB e RTP, adaptadas para SCTP, foram postas prova, com os bons resultados, na verdade esperados, para HTTP e RTP. A adaptao do SMB, que era simples mas esperava-se entregaria performance melhor que TCP, apresentou resultados piores que TCP. Essa adaptao teria de ser aprofundada para extrair-se a vantagem teoricamente prevista. De tudo isso, conclui-se que o SCTP um protocolo que merece a ateno dos desenvolvedores de aplicativos e de protocolos de aplicao, pois possui recursos atraentes, e ao menos uma implementao de qualidade muito prxima de produo.

88

Como itens para trabalhos futuros que abordem o SCTP, sugere-se:

Extenso para desligamento do checksum CRC-32c, que redundante em conexes de rede local como Ethernet que j implementa CRC-32 na camada de enlace. Tal desligamento tambm serviria para mensurar o impacto real do CRC-32c sobre a latncia, bem mais alta que a do TCP conforme mostram os testes deste trabalho. O desligamento do checksum deve ser acompanhado de mudanas no funcionamento interno do driver de kernel, visando diminuir o nmero de cpias dos dados, pois o simples desligamento feito num teste preliminar mostrou que o ganho de desempenho relativamente pequeno; Alteraes no algoritmo de controle de congestionamento, para melhor adaptao perda constante de pacotes; Vericao da segurana do SCTP em diversas implementaes, particularmente a gerao de ISN e etiquetas de vericao para novas associaes, que deve ser sucientemente imprevisvel para evitar blind spoof ; Adaptao ou elaborao de protocolos de aplicao que possam aproveitar de mltiplos uxos SCTP para aumento da vazo, nos moldes do relatrio de KANG & FIELDS; Adaptao de protocolos de aplicao de uso generalizado ao SCTP, e a proposio das adaptaes como RFCs; Anlise aprofundada do transporte de contedo multimdia em tempo real sobre SCTP, em particular a adaptao da taxa e do prazo de validade das mensagens, de acordo com o RTT e as perdas entre cliente e servidor.

Todos os softwares utilizados, tanto os construdos para o teste quanto os softwares de terceiros, esto disponveis no CD encartado. O mesmo para o cdigo-fonte deste documento e seus grcos associados, vrias RFCs, e planilha eletrnica com os resultados detalhados dos testes.

ANEXO 1: Caractersticas de segurana do SCTP

Os protocolos de transporte da pilha TCP/IP no foram inicialmente projetados com o objetivo de proporcionar segurana. O protocolo TCP tem alguma segurana, mais incidental que propositada, contra ataques cegos (spoof), mas sensvel a ataques de negao de servio (DoS). As fraquezas do TCP so graves pois o protocolo de transporte mais utilizado, e a maioria das aplicaes no apresenta qualquer mecanismo adicional de segurana. As duas principais fraquezas do TCP so:

no autenticar as partes durante a criao da conexo; alocar recursos do servidor antes de a conexo estar completamente aberta.

A nica proteo do TCP contra ataques blind spoof conar que cada terminal gere nmeros iniciais de seqncia (ISN initial sequence number) imprevisveis. Essa imprevisibilidade foi prevista pelos criadores do TCP, porm como forma de distinguir mais facilmente encarnaes diferentes da mesma conexo (i.e. conexo envolvendo mesmos endereos e portas). A implicao de segurana do ISN imprevisvel foi percebida mais tarde. Assim como uma conexo aberta, a conexo meio-aberta TCP ocupa uma estrutura TCB (Transmission Control Block) , pois lado passivo da conexo (tipicamente o servidor) precisa armazenar o ISN remetido pelo cliente no pacote SYN. Como em geral o TCP implementado no kernel do sistema operacional, e a memria do kernel limitada, o nmero mximo de TCBs, e portanto o nmero de conexes TCP simultneas, tem um limite bem denido. Assim, um invasor pode simplesmente disparar um grande nmero de pacotes TCP SYN com origem falseada o ataque SYN ood. As conexes meio-abertas nunca so efetivadas e acabam descartadas por timeout, porm nesse meio tempo elas ocupam todos os TCBs disponveis e impedem a realizao de conexes legtimas (BERNSTEIN). Felizmente, h uma tcnica que praticamente elimina essa fraqueza do TCP: o SYN cookie. Consiste de um ISN gerado pelo servidor por um algoritmo criptogrco descrito por BERNSTEIN.

90

Depois de calcular o ISN e remeter o segundo pacote de handshake, o servidor no aloca TCB e no armazena nada sobre a conexo meio-aberta. Pode-se armar que o SYN Cookie transfere a responsabilidade do armazenamento da conexo meio-aberta para o cliente e para a rede. Se o cliente for legtimo e remeter o terceiro pacote de handshake, o servidor reconhece o seu ISN matematicamente, e s ento atribui um TCB conexo totalmente aberta. Os SYN cookies funcionam, mas o nmero de seqncia (32 bits) algo pequeno para ns de autenticao criptogrca. O uso de SYN cookies diminui a aleatoriedade do ISN. Por esse motivo, costuma ser ativado apenas quando h indcios de ataque e os TCBs esto escasseando. Um novo ataque de negao de servio contra o TCP, na verdade j conhecido h muito tempo, mas considerado apenas um risco terico, tem se tornado provvel com o aumento da velocidade da Internet, tanto nos backbones como nos terminais. o simples disparo de pacotes RST (abortamento de conexo), com origem falseada, contra participantes de uma conexo legtima. O agente hostil precisa conhecer os endereos IP e nmeros de porta envolvidos, o que s provvel quando as vtimas usam padres repetitivos de conexo. As principais vtimas em potencial so os roteadores globais da Internet, que utilizam o protocolo BGP, pois este ltimo cria conexes TCP de longa durao e em portas xas. A proteo do TCP contra esse tipo de ataque rejeitar pacotes cujo TSN esteja fora da janela atual. Com um TSN de 32 bits e uma janela tpica de 4Kbytes, a chance de aceitar um RST falseado de aproximadamente uma em um milho (1 em 2 3212 ) . Porm:

a disponibilidade de enlaces de banda larga (v.g. ADSL) tornou possvel a um usurio domstico emitir grande quantidade de pacotes por unidade de tempo; as conexes TCP tendem a usar janelas cada vez maiores (64Kbytes ou maiores) para mxima performance, aumentando a probabilidade de aceitar um pacote falseado; os ataques podem ser (e so) desfechados de forma distribuda, inclusive por vrus.

Tudo isso pode trazer problemas muito srios ao TCP em breve. Os protocolos MDTP e SCTP foram desde o incio projetados com salvaguardas de segurana contra os ataques descritos (STEWART & XIE, 2002).

91

4-way handshake Em primeiro lugar, a criao da associao usa 4 pacotes, 2 em cada direo, o que permite um handshake mais elaborado. Os ltimos dois pacotes de handshake j podem transmitir mensagens, de modo a iniciar a transmisso de dados o mais rpido possvel. Em tese, o terceiro pacote de handshake TCP tambm pode transmitir dados. Mas a API BSD Sockets retorna de connect() apenas depois que o terceiro pacote j foi transmitido. Felizmente, a extenso do Sockets para SCTP no apresenta o mesmo problema pois abre as associaes de forma diferente. Os pacotes envolvidos na criao da associao, listados na seqncia normal de transmisso, tm os seguintes nomes (STEWART et al, 2000): INIT, do cliente para o servidor (cliente quem toma a iniciativa da abertura); INIT-ACK, do servidor para o cliente em resposta a INIT; COOKIE-ECHO, do cliente para o servidor. Ao receb-lo, o servidor considera estabelecida a associao; COOKIE-ACK, do servidor para o cliente, conrmando o recebimento de COOKIE-ECHO. Ao receb-lo, o cliente considera estabelecida a associao. Etiqueta de vericao (verication tag) Na parte xa da estrutura do pacote SCTP, existe um parmetro de 32 bits denominado etiqueta de vericao (verication tag). Cada associao possui duas etiquetas, uma para cada direo. No existe nada semelhante em TCP. Nos pacotes INIT e INIT-ACK, cada lado calcula e transmite uma etiqueta de inicializao (initiation tag), e dali por diante deve repetir esse valor na etiqueta de vericao de todos os pacotes daquela associao. Todo pacote SCTP deve apresentar a etiqueta correspondente sua associao e direo, sob pena de ser descartado (STEWART et al, 2000). Essa etiqueta serve primariamente para identicar encarnaes diferentes de uma mesma associao (i.e. entre os mesmos terminais e os mesmos nmeros de porta). Mas tambm permite discriminar facilmente pacotes forjados, eliminando assim a possibilidade de blind spoof, tanto na tentativa de abertura de conexes annimas quanto na tentativa de seqestro ou abortamento de uma conexo existente. O valor da etiqueta deve ser imprevisvel para agentes externos, para que a proteo contra blind spoof seja efetiva. o mesmo cuidado que deve ser tomado na gerao do ISN do TCP, ou do ISN do SCTP, visto a seguir.

92

Nmero de seqncia de transmisso (TSN) O TCP apresenta o parmetro TSN (transmission sequence number nmero de seqncia de transmisso) para indicar, em cada pacote, qual o segmento da seqncia de octetos que est sendo transmitido. Esse valor permite remontar a seqncia e detectar as lacunas. No TCP, o TSN incrementado pelo nmero de octetos transmitidos. O SCTP tambm apresenta o TSN nos trechos de dados, e sua utilidade idntica ao TSN no TCP, exceto pelo fato de ser incrementado por trecho, e no por octeto. Da mesma forma que no TCP, o TSN inicial (ISN) informado de parte a parte durante a criao da associao, e tal qual TCP ele deve ser imprevisvel por parte de um agente externo. Mas o TCP conta apenas com esse recurso para detectar ataques blind spoof que visem abortar ou seqestrar uma conexo. J o SCTP conta com o TSN e tambm com a etiqueta de vericao, tornando-se bem mais resistente. A RFC 2960 (STEWART et al., 2000) sugere inicialmente que o ISN poderia ser uma duplicata da etiqueta de vericao, pois ambos tm o mesmo tamanho. Porm, STEWART & XIE (2002) recomendam em seu livro que a gerao dos dois valores seja independente para aumentar a resistncia a ataques. Cookies Eliminado o blind spoof, resta evitar que o lado passivo da associao SCTP aloque TCBs com associaes meio-abertas e que vulnervel a ataque anlogo ao SYN ood. Assim como no SYN Cookie do TCP, a soluo do SCTP transferir para o cliente a responsabilidade total pelo armazenamento dos dados da associao meio-aberta, atravs dos cookies. O cookie SCTP uma estrutura de tamanho varivel, opaca (i.e. apenas o criador conhece seu formato interno), que o servidor transmite ao cliente no pacote INIT-ACK. O cliente deve retransmitir o cookie ao servidor no pacote COOKIE-ECHO, como sugere o prprio nome do pacote. Se o cliente for na verdade um agente hostil cego mandando pacotes forjados, o cookie nunca chegar de volta ao cliente, nem ser devolvido ao servidor. Como o servidor no ocupa memria com associaes meio-abertas, o ataque no satura a tabela de associaes e no impede as associaes legtimas. Ataques no estilo SYN ood no so viveis contra o SCTP.

93

Aps transmitir o pacote INIT-ACK, o servidor no conserva nenhuma informao sobre a associao, nem sobre o potencial cliente, e a associao s efetivada com o pacote COOKIE-ECHO. Portanto, o servidor depende exclusivamente das informaes contidas no cookie para criar a associao. Logo, embora o formato do cookie seja de livre escolha, ele tem de conter obrigatoriamente os seguintes dados:

os dados relevantes do pacote INIT. Normalmente ser uma simples transcrio dos dados do pacote; os dados relevantes (gerados pelo servidor) do pacote INIT-ACK. Normalmente ser tambm uma simples transcrio; duas etiquetas de 32 bits denominadas tie tags. Normalmente, essas etiquetas contm o valor zero, mas podem ser eventualmente preenchidas com as etiquetas de vericao do cliente e/ou do servidor. Elas servem para identicar retransmisses de pacotes de criao de associao.

Os dados acima so o minimo necessrio para a implementao funcionar, porm mais alguns so necessrios para garantir a segurana do SCTP:

timestamp para que cookies velhos possam ser descartados, bem como para proteo contra ataques de repetio (replay attacks); assinatura digital que garanta a integridade dos dados, permita ao servidor reconhecer o cookie como seu, e atrele o cookie ao cliente.

KARN e KRAWCZYK et al. descrevem os mecanismos para a gerao de um cookie seguro. A assinatura digital tipicamente obtida concatenando-se todos os dados do cookie, os endereos IP, as portas, uma chave secreta e calculando-se um hash de qualidade criptogrca. (KRAWCZYK et al. sugere MD5 ou SHA-1). A RFC 2960 recomenda que a chave secreta seja trocada de forma razoavelmente freqente. Deve haver uma janela de aceitao da chave velha para evitar que associaes em fase de criao sejam incorretamente ilegitimadas. Obviamente, a chave secreta concatenada apenas na memria do servidor para ns de clculo do checksum, e no vai fazer parte do cookie transmitido.

94

A criptograa dos dados do cookie no especialmente encorajada, pois no traz qualquer vantagem de segurana; os dados ali contidos poderiam ser obtidos facilmente de outras formas. O hash suciente para ns de autenticao. Embora a implementao seja livre para escolher o tamanho do cookie, deve procurar escolher o menor tamanho possvel para evitar problemas de interoperabilidade. Se considerarmos 16 octetos para os dados relevantes de INIT, mais 16 para os dados de INIT-ACK, 8 para os tie-tags, 8 para o timestamp e 16 para a assinatura digital, chegamos a um cookie de 64 octetos. Somatrio de vericao (checksum) Segundo SHANNON, um checksum de n bits pode detectar, no mximo:

100% dos erros de at n bits; 2n 1 em cada 2n erros que afetem aleatoriamente mais de n bits.

Este o melhor desempenho teoricamente possvel (o trabalho de Shannon no descreveu como criar somatrios ecazes); algoritmos reais tero menor capacidade de deteco. O algoritmo CRC aproxima a expectativa da previso terica para erros em rajadas, desde que seu polinmio gerador seja bem escolhido. Isso vale no s para nmeros binrios. O dgito vericador presente em nmeros de conta bancria tem as mesmas propriedades: detecta 100% dos erros simples de digitao, e deixa passar 10% dos demais erros se o algoritmo gerador for de boa qualidade, como o Mdulo 11. O TCP checksum, somatrio utilizado em TCP e UDP, menos eciente que o CRC na deteco de erros, mas ainda detecta 100% dos erros de 1 bit que constituem a grande maioria dos erros e muito mais eciente no clculo por software que o CRC. (Deve-se levar em conta que essa escolha foi feita numa poca em que as CPUs tinham velocidade muito menor que hoje.) Em mdia, 1 em cada 5000 pacotes da Internet (0,2%) entregue com algum erro (ARIAS-RODRIGUEZ apud PAXSON). Os meios de transmisso da Internet so muito conveis (v.g. Ethernet e FDDI usam CRC-32) e no justicam tamanha quantidade de erros. Os erros so na verdade provocados majoritariamente por problemas nos roteadores desde memria de m qualidade, interferncia eletromagntica at bugs na implementao dos respectivos softwares.

95

16

Um checksum de 16 bits, por melhor que seja seu algoritmo, deixa passar 1 em dos pacotes errados, para erros completamente aleatrios. Isso signica que 1 em

327.680.000 (5000 65536) dos pacotes da Internet entregues camada de aplicao contm erros. uma chance de erro pequena, porm observvel, o que obriga a camada de aplicao a implementar algum mecanismo adicional de proteo. HTTP e FTP no possuem tal mecanismo, e portanto no so conveis para transmisso de dados sensveis, se a integridade dos arquivos no vericada de outra forma. Como o SCTP tem a pretenso de transmitir mensagens de telefonia, o grau de conabilidade tem de ser mais alto que o oferecido pelo checksum de 16 bits. E estabelecer essa conabilidade no protocolo de transporte desonera as aplicaes dessa tarefa. O checksum inicialmente escolhido para o SCTP foi o Adler-32. Pesquisas posteriores determinaram que o poder de deteco de erros desse algoritmo fraco para mensagens menores que 1 Kbyte (que o caso do pacote SCTP tpico). O cdigo CRC antigo, mas ainda dos mais poderosos na deteo de erros. Sua principal desvantagem a lentido no clculo por software (embora seja rpido em hardware). Aps muita deliberao, optou-se nalmente pelo CRC-32c. Levou-se em conta o grande poder de processamento dos dispositivos modernos. A mudana de checksum do SCTP est ocializada na RFC 3309 (STONE et al, 2002). Quanto escolha do polinmio gerador, a primeira opo foi o CRC-32 tradicional utilizado em Ethernet e FDDI, porm o polinmio CRC-32c protege melhor mensagens pequenas, de modo que acabou este ltimo sendo o eleito para o SCTP. Um checksum timo de 32 bits deixa passar apenas 1 em 232 pacotes errados, para erros completamente aleatrios. Levando em conta a taxa de erros da Internet (1 em 5000), o SCTP entregaria aplicao apenas 1 pacote errado a cada aproximadamente 21.474.836.480.000 trafegados, ou seja, a entrega de uma mensagem corrompida aplicao virtualmente impossvel. O somatrio CRC no uma assinatura digital e portanto no protege os dados contra fraude. Sem garantias criptogrcas Os mecanismos de segurana do SCTP evitam apenas os ataques cegos. O SCTP no oferece por conta prpria garantias criptogrcas (condencialidade, autenticidade, integridade), nem resistente a ataques do homem do meio. Tais garantias de segurana podem ser providas por outros protocolos, e.g. IPSEC e SSL.

96

A utilizao de SSL com SCTP est descrita na RFC 3436 (JUNGMAIER et al, 2002). As questes de utilizao de IPSEC com SCTP em multicaminhos so descritas em BELLOVIN et al.

ANEXO 2: Detalhes de funcionamento do protocolo SCTP

Formato dos pacotes O pacote SCTP possui um cabealho xo de 4 parmetros (12 octetos), mais um nmero varivel de trechos (chunks) alinhados em 32 bits, conforme o esquema abaixo. Os parmetros xos esto em negrito.
Cabealho IP Porta de origem (16 bits) Porta de destino (16 bits)

Etiqueta de vericao (32 bits) Somatrio de vericao (32 bits) Trecho 1 (trechos alinhados em 32 bits) Trecho 2 Trecho n

Toda a troca de informaes de controle do SCTP (abertura de associao, fechamento de associao etc.) feita atravs de trechos de tamanho varivel, e no bitmaps como em TCP. Os nmeros de porta de origem e destino tm o mesmo m que em TCP e UDP. A funo dos demais campos detalhada no ANEXO 1. Notar que as portas esto nas mesmas posies relativas utilizadas por TCP e UDP, o que facilita a interpretao desses nmeros por aplicativos de diagnstico de rede. Os primeiros 8 octetos do cabealho SCTP contm todas as informaes necessrias para identicar univocamente uma associao, consoante com as mensagens ICMP que incluem no mnimo 8 octetos do pacote que provocou o erro. Como em todo protocolo da pilha TCP/IP, os dados que representam nmeros inteiros devem ser representados em network byte order o primeiro octeto o mais signicativo. Os trechos so estruturas de dados TLV (type, length, value tipo, comprimento e valor). So alinhados em 32 bits e podem apresentar at 3 octetos de enchimento. O valor do comprimento inclui os 4 octetos dos trs primeiros campos, porm no inclui o enchimento.
Tipo (8 bits) Flags (8 bits) Comprimento (16 bits)

Dados teis do trecho, mais enchimento (32n bits)

98

O parmetro Flags um mapa de bits interpretado de acordo com o tipo de trecho (no h nenhum ag com signicado genrico). Como o SCTP foi projetado para ser extensvel, pode suceder de um tipo de trecho presente em uma implementao no ser suportado por outras implementaes. A reao do receptor a um trecho no suportado depende dos dois bits MSB do tipo de trecho:
Tipo 0x00 a 0x3F 0x40 a 0x7F 0x80 a 0xBF 0xC0 a 0xFF Ao tomada pelo receptor, se no suporta o trecho descartar o pacote que contm o trecho descartar o pacote e remeter uma noticao de erro desprezar o trecho e continuar a processar o pacote desprezar o trecho, continuar a processar o pacote, e remeter uma noticao de erro

O cdigo do tipo deve ser escolhido em funo da reao desejada. No espao de dados teis, os trechos predenidos pelo protocolo tm parmetros permanentes e opcionais. Os parmetros permanentes tm tamanho e ordem predenidos para cada tipo, tal qual uma estrutura da linguagem C, e sempre vm primeiro em relao aos parmetros opcionais. O bloco de parmetros permanentes deve ser alinhado em 32 bits. Em seguida vm os parmetros opcionais, em nmero varivel, que tambm so estruturas TLV:
Tipo de parmetro (16 bits) Comprimento (16 bits)

Dados teis do parmetro, mais enchimento (32n bits)

Assim como nas estruturas TLV dos trechos, o comprimento do parmetro inclui os 4 octetos do tipo e do prprio comprimento, mas no inclui os octetos de enchimento. Analogamente ao tipo de trecho, os dois bits MSB do tipo de parmetro tambm especicam a reao a um parmetro desconhecido pelo receptor:
Tipo de parmetro 0x0000 a 0x3FFF 0x4000 a 0x7FFF 0x8000 a 0xBFFF 0xC000 a 0xFFFF Ao tomada pelo receptor, se no suporta o parmetro descartar o trecho que contm o parmetro descartar o trecho e remeter uma noticao de erro desprezar o parmetro e processar o trecho desprezar o parmetro, processar o trecho, e remeter uma noticao de erro

99

Motivao de uso da estrutura TLV A estrutura TLV simples de entender, implementar e processar, e sem dvida muito mais verstil que um bitmap xo. Alguns testes realizados por Randall Stewart (um dos criadores do SCTP), citados por ARIAS-RODRIGUEZ, determinaram que o processamento de uma estrutura TLV mais rpido que o de um bitmap. O bitmap no de todo desvantajoso. Ele pode ser muito pequeno, reduzindo a sobrecarga de rede. Protocolos como IP e TCP utilizam bitmaps, pois, poca de sua criao, as baixas velocidades dos enlaces justicavam qualquer esforo de diminuio da sobrecarga. A situao atual, segundo TANENBAUM, oposta - a vazo limitada predominantemente pela latncia de processamento dos terminais, e a reduo dessa latncia deve ser a principal preocupao dos projetistas de protocolos. Os protocolos devem ser simples, geis no processamento e extensveis. Desta forma, o SCTP utiliza majoritariamente estruturas TLV para transporte de dados e informaes de controle. At mesmo tarefas como abertura e fechamento de associao utilizam tais estruturas, e no ags (e.g. ACK, SYN, FIN do TCP). Suporte ao SCTP em aplicativos-ferramentas A alocao de todas as informaes em estruturas TLV torna mais difcil a interpretao dos pacotes SCTP por parte de ferramentas de diagnstico de rede. No basta enquadrar o pacote numa estrutura C; a ferramenta precisa conhecer sucientemente o protocolo para separar e interpretar os TLVs. Como o prprio payload est encapsulado em uma estrutura TLV, a gura didtica da separao rgida entre cabealho de transporte e payload, no existe em SCTP. Um pacote SCTP pode ter dois ou mais trechos de dados, ento haver dois payloads incrustados dentro das estruturas de controle SCTP. Em TCP e UDP, a tupla formada pelos pelos endereos e portas dos terminais identica univocamente uma conexo, mesmo na Internet. Pode-se comear a monitorar uma conexo a qualquer momento, e individualiz-la imediata e facilmente. Em SCTP, o suporte a multicaminhos torna mais difcil a individualizao da associao. Para uma identicao perfeita, o aplicativo tem de monitorar a associao desde sua criao, para conhecer os endereos alternativos informados de parte a parte. Se o monitoramento comear com a associao multicaminhos j estabelecida, a individualizao ser imperfeita. As tuplas formadas pelas etiquetas de vericao podem

100

ser usadas como dado auxiliar de individualizao, mas no so perfeitas pois existe sempre a (na verdade muito pequena) probabilidade de associaes diferentes apresentarem as mesmas etiquetas. Embora no sejam problemas insolveis, certamente os fatores acima tm atrasado o suporte a SCTP em aplicativos-ferramentas, bem como em equipamentos ativos de rede. Decises de implementao Conforme a RFC 2960 (STEWART et al, 2000), h algumas decises deixadas implementao do protocolo SCTP. Maior mensagem suportada Muito embora o tamanho mximo terico da mensagem seja de 2 32 1 octetos, a implementao pode estabelecer um limite prtico menor. Um dos limites o tamanho mximo do buffer de recepo, que est na memria do kernel e sofre restrio relativamente severa de tamanho. Outro limite prtico imposto pelo PTMU da rede e pelos 16 bits do SSN uma mensagem pode ser fragmentada em no mximo 2 16 trechos, o que limita seu tamanho a 216 P M T U . tambm facultada implementao limitar a mensagem ao PMTU, de modo que caiba integralmente em um datagrama e dispense o algoritmo de remontagem de mensagens. Dispositivos de memria restrita como celulares podem determinar tais restries. Mensagens SS7 podem ter, no nvel de aplicao, no mximo 272 ou 4091 octetos, dependendo do meio de transmisso (ONG et al, 1999); dispositivos que utilizem SCTP exclusivamente para sinalizao de telefonia podem ater-se a esses limites. Formato do cookie O tamanho e forma de gerao do cookie de autenticao de responsabilidade da implementao. As RFCs 2522 e 2104 sugerem algoritmos e fontes de dados para ele. A implementao tambm pode restringir o tamanho mximo do cookie recebido, por limitaes de memria etc. Isso limita sua interoperabilidade com outras implementaes que usem cookies maiores. Por esse motivo, e prevendo que o SCTP possa ser usado em dispositivos naturalmente limitados em capacidade de memria e processamento, a RFC 2960 recomenda que a implementao crie o menor cookie possvel.

101

Suporte a multicaminhos A implementao de multicaminhos opcional em cada uma de suas modalidades (endereos IPv4, endereos IPv6 e nomes DNS). Por exemplo, uma implementao pode suportar apenas multicaminhos com endereos IPv4. Isso interessante se o sistema operacional subjacente no suporta IPv6 se todas as modalidades fossem obrigatrias, sistemas sem IPv6 estariam impedidos de implementar SCTP. Tambm possvel que algumas implementaes optem por no suportar multicaminhos baseado em endereos DNS, por questes de segurana. Ainda, em alguns dispositivos, no faz nenhum sentido usar multicaminhos. Suporte a conabilidade parcial (PRSCTP) A extenso PRSCTP modica a semntica do prazo de validade das mensagens. Uma mensagem cujo prazo de validade estoure, descartada mesmo que sua transmisso j tenha sido tentada. Ela de implementao opcional. Convivncia do SCTP com outras tecnologias A grande maioria dos problemas de convivncia do SCTP com outras tecnologias de rede TCP/IP so derivadas do recurso de multicaminhos. IPv6 As verses iniciais do SCTP previam apenas multicaminhos para IPv4, o que era uma grande limitao. Felizmente, o suporte a multicaminhos IPv6 foi introduzido numa das revises do protocolo. O SCTP permite at mesmo mistura de endereos IPv4 e IPv6 para multicaminhos de uma mesma associao. Uma observao importante, encontrvel na RFC 2960, que no se pode usar um parmetro de endereo IPv6 contendo um endereo IPv4 mapeado em IPv6 (::FFFF:0/96). Para endereos IPv4, deve-se utilizar o parmetro de endereo IPv4, contendo o endereo IP de 32 bits. Roteadores NAT NAT para SCTP sem multicaminhos tem o mesmo grau de diculdade que TCP. A priori no faz sentido fazer NAT para SCTP com multicaminhos, pois h muitas variveis envolvidas:

102

Haver apenas um roteador NAT envolvido, ou um NAT para cada caminho? Se houver mais de um roteador NAT envolvido, como os NAT secundrios caro sabendo da associao, se os pacotes INIT, INIT-ACK etc. trafegaram apenas pelo NAT primrio? Quem multicaminhos: o terminal ou o roteador NAT? Existe mistura de endereos vlidos e invlidos? Quem dene que endereos devem ou no ser traduzidos?

No caso especco do terminais ocultos monocaminhos, e um nico roteador NAT multi-homed, existe um potencial interessante de aumentar a tolerncia a falhas. Conforme a alternativa proposta por COENE, o protocolo SCTP foi estendido para aceitar endereos multi-homed em forma de nome DNS. Os computadores "ocultos" podem tirar proveito do roteador NAT multi-homed, desde que informem como caminhos alternativos os nomes DNS do roteador NAT. Mais fcil ainda associar um nico nome DNS a todos os endereos IP dos caminhos. responsabilidade do terminal remoto fazer a resoluo DNS do nome. Como o SCTP deve em geral ser implementado no kernel dos sistemas operacionais, e o protocolo DNS em geral est fora do kernel, provvel que as implementaes escolham entre:

no suportar multicaminhos com nomes DNS; criar um processo-agente que resolva nomes DNS para o kernel, com alguma proviso de segurana contra ataques de negao de servio.

IPSEC O IPSEC autentica (cabealho AH) e opcionalmente criptografa (cabealho ESP) cada pacote IP de modo que:

o receptor tenha certeza de que o pacote veio da origem alegada, e que o pacote no foi forjado, adulterado ou danicado; a origem no possa negar que emitiu o pacote, nem negar a autoria dos dados contidos nele; opcionalmente, haja condencialidade dos dados;

103

opcionalmente, haja condencialidade dos endereos IP dos terminais (possvel com o modo tnel).

Para oferecer essas garantias, o IPSEC faz uso de chaves pblicas, e h troca de chaves secretas entre as partes antes de qualquer comunicao de dados do usurio. As chaves secretas so atreladas aos endereos IP das partes. O IPSEC opera em dois modos distintos:

Modo transporte: o IPSEC empacota apenas o payload (dados teis) do datagrama IP. Este modo no pode garantir a condencialidade do cabealho IP, porm permite estabelecer um canal seguro de comunicao entre dois terminais IPSEC quaisquer da Internet; Modo tnel: o IPSEC reempacota inteiramente o datagrama IP, formando um tnel ou VPN. Este modo pode garantir a condencialidade do cabealho IP, mas exige providncias administrativas explcitas nas duas extremidades do tnel.

Nada disso interfere com os protocolos de transporte, nem impede que se use o SCTP com IPSEC. O problema surge na interao do modo transporte com multicaminhos. Toda a negociao da associao SCTP (e a negociao IPSEC que a precede) feita entre os IPs primrios dos terminais. Se, durante a associao, o IP primrio falhar, o SCTP tentar mandar dados para um IP secundrio do terminal remoto, que rejeitar os pacotes pois h discrepncia entre o cdigo de autenticao e o endereo IP de destino. A alternativa mais fcil, que funciona com o IPSEC sem modicaes, efetuar a negociao IPSEC entre todos os endereos envolvidos. Esse produto cartesiano pode no ser adequado se o nmero de endereos grande se ambos os terminais tm 5 endereos IP diferentes, teria de haver 25 negociaes IPSEC, que envolvem busca de chave pblica e clculos relativamente demorados. Outra alternativa estender o IPSEC para tratamento de multicaminhos, possibilitando uma nica negociao vlida a todos os endereos da associao. A soluo denitiva para este problema ainda est em discusso (BELLOVIN et al.). O mais provvel que a escolha da estratgia seja delegada s implementaes.

ANEXO 3: Extenses da interface BSD Sockets para suporte ao protocolo SCTP

O documento autoritativo das extenses interface BSD Sockets para suporte a SCTP, STEWART et al. (2004a). Este documento ainda um rascunho (draft), sujeito a revises antes de ser promovido a RFC. Apesar disso, as extenses j foram implementadas em diversos sistemas operacionais. A aplicao pode fazer uso do SCTP atravs de dois tipos de soquetes:

Estilo TCP: cada soquete corresponde a uma associao, que funciona de forma semelhante a um soquete de conexo TCP. Estilo UDP: vrias associaes atreladas a um soquete. Existe certa semelhana com um soquete UDP pois este ltimo permite trocar pacotes com qualquer terminal remoto.

Objetiva-se com isso oferecer convenincia para aplicativos novos, e facilidade de converso de aplicativos existentes (a maioria deles simplesmente migrando de TCP para SCTP sem quaisquer mudanas no protocolo de aplicao). Estilo TCP O estilo TCP torna extremamente simples a converso de programas que j utilizem TCP. Em geral, preciso mudar apenas o terceiro parmetro passado a socket(); nenhuma outra mudana necessria.

// cliente sockaddr_in servidor; int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); servidor.sin_family = AF_INET; servidor.sin_addr.s_addr = inet_addr(10.0.1.1); servidor.sin_port = 12345; connect(fd, (sockaddr&) &servidor, sizeof(servidor)); // ... comunica-se com servidor com send() e recv() ... close(fd);

105

// servidor sockaddr_in serv, cliente; int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); serv.sin_family = AF_INET; serv.sin_addr.s_addr = INADDR_ANY; serv.sin_port = htons(12345); bind(fd, (sockaddr*) &serv, sizeof(serv)); listen(fd, 5); while (true) { int fd_conexao = accept(fd, (sockaddr*) &cliente, sizeof(cliente)); // ... trata cliente com send() e recv() ... close(fd_conexao); }

A funo shutdown() suportada em SCTP porm simplesmente fecha a conexo sem liberar o manipulador de arquivo. SCTP no suporta o estado meio-fechado. As funes send() e write() transmitem os dados pelo uxo zero. As funes recv() e read() recebem mensagens vindas de qualquer uxo. O aplicativo no tem como saber por que uxo veio a mensagem. Se o terminal remoto utilizar mltiplos uxos ou mensagens urgentes, a ordem de entrega dos dados imprevisvel. Cada chamada a send() gera uma mensagem atmica, semelhante a sendto() em UDP. A atomicidade das mensagens respeitada por recv(), desde que o buffer de recepo seja sucientemente grande, sob pena da mensagem ser entregue parcialmente (o que destri sua atomicidade). O aplicativo pode utilizar select() ou poll() para aguardar transmisso e recepo, tal qual faria em TCP. possvel utilizar diversos uxos e mensagens urgentes no estilo TCP, mas o aplicativo dever utilizar as funes avanadas de I/O, abordadas mais adiante neste anexo. Mesmo utilizando tais funes, o aplicativo no receber informaes avanadas do estado da associao (e.g. estado de cada caminho). Tais informaes so visveis apenas no estilo UDP. Para congurar o nmero de uxos de uma nova associao neste estilo, necessrio recorrer a setsockopt(SCTP_INIT). Estilo UDP O estilo UDP oferece um paradigma mais interessante para o tratamento de grande nmero de associaes.

106

Uma caracterstica interessante desse estilo que o aumento na complexidade do cdigo-fonte aproximadamente proporcional ao nvel de controle desejado sobre as associaes e mensagens. As diferenas entre os soquetes SCTP estilo UDP e UDP legtimo tambm vo aumentando.

sockaddr_in local, remoto; int fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP); local.sin_family = AF_INET; local.sin_addr = INADDR_ANY; local.sin_port = htons(54321); bind(fd, (sockaddr*) &local, sizeof(local)); // aceitar associaes passivamente (como servidor) // um cliente puro no faria isto listen(fd, 5); // timeout de 2 minutos (120 segundos) int timeout = 120; setsockopt(fd, SCTP_AUTOCLOSE, &timeout); remoto.sin_family = AF_INET; remoto.sin_addr.s_addr = inet_addr(10.0.1.1); remoto.sin_port = htons(12345); char *mensagem = a mensagem; sendto(fd, (sockaddr*) &remoto, mensagem, strlen(mensagem)+1); // ... comunica-se com outros terminais // usando sendto() e recvfrom() ... close(fd);

No h criao explcita de associao. As associaes so abertas sob demanda, e cam todas atreladas a um nico soquete. Elas so fechadas automaticamente por desuso; o timeout congurado atravs de setsockopt(SCTP_AUTOCLOSE). O aplicativo ca livre de toda a burocracia de tratamento das associaes, mesmo que faa uso de milhares delas. O uso de um nico manipulador de arquivo tambm aumenta a escalabilidade do aplicativo. Como no necessrio chamar connect() para criar a associao, a implementao pode usar os pacotes COOKIE-ECHO e COOKIE-ACK para transmitir dados, o que colabora para diminuir a latncia. De qualquer forma, se o aplicativo deseja abrir uma associao sem mandar dados imediatamente, ainda pode usar connect() para esse m. O TCP tambm pode, em tese, transmitir dados no terceiro pacote de handshake, mas a chamada a connect() s retorna depois da conexo completamente aberta (STEVENS et al, 2004).

107

Se o aplicativo deseja fazer abertura passiva de associaes (i.e. atuar como servidor), deve chamar listen() para o soquete. (Note que essa chamada no faria sentido para UDP.) Em alguns aplicativos de servidor, em particular aplicativos multithreaded, pode ser vlido destacar uma associao para seu prprio manipulador de arquivo. Para esse m, foi criada uma nova funo, sctp_peeloff(). Uma vez destacada, a associao no mais pode ser acessada pelo soquete genrico, nem ser automaticamente fechada por desuso. Apenas associaes podem ser destacadas; no h forma de destacar um uxo em particular. A funo sendto() transmite os dados pelo uxo zero. A funo recvfrom() recebe mensagens vindas de qualquer uxo; o aplicativo no ter como saber de que uxo veio a mensagem. Cada chamada a sendto() gera uma mensagem, tal qual UDP. A atomicidade das mensagens respeitada por recvfrom(), desde que o buffer de recepo seja sucientemente grande, sob pena de entrega parcial e perda da atomicidade. O fechamento do soquete genrico fecha todas as associaes atreladas. Para fechar uma associao em particular, o aplicativo deve usar o estilo UDP avanado, ou ento fechar o manipulador destacado por sctp_peeloff(). Como o soquete genrico est ligado a muitas associaes, no faz sentido usar select() para aguardar o momento da transmisso. No seria possvel saber que associaes esto prontas para transmitir. A soluo mais elegante usar I/O no-bloqueante. Pode ser inclusive perigoso a um aplicativo single-threaded usar o soquete genrico em modo bloqueante, pois sendto() bloqueia se o buffer de transmisso da associao estiver cheio. E enquanto o aplicativo dorme, milhares de outras associaes podem estar esperando para entregar mensagens (STEWART et al, 2004a). Por essas razes, provavelmente toda aplicao deveria usar o soquete genrico em modo no-bloqueante. Uma alternativa menos escalvel, mas confortvel ao desenvolvedor que no quer lidar com I/O no-bloqueante, destacar todas as associaes com sctp_peeloff() e fazer select() sobre todos os manipuladores (inclusive sobre o genrico, pois atravs dele que criam-se novas associaes ativa ou passivamente). Interface avanada de I/O Nos estilos TCP e UDP bsicos, no existe forma de especicar o uxo de transmisso, ou conhecer por que uxo veio uma mensagem, ou ainda de marcar uma mensagem

108

como urgente Para ter acesso a todos os recursos do SCTP, o aplicativo enviar e receber dados atravs da coleta de dados auxiliares (funes sendmsg() e recvmsg()). Uma descrio pormenorizada do uso de coleta de dados auxiliares pode ser encontrada em STEVENS et al. (2004).. Essa interface mais complexa, porm permite:

tanto no estilo TCP quanto no estilo UDP, transferir mensagens atravs de estruturas, que (alm dos dados) contm os parmetros SCTP: uxo, urgncia, identicao de protocolo etc; no estilo UDP, receber e enviar eventos, como abertura e fechamento de associaes, mudana no estado do enlace etc. para que o aplicativo possa ter, se quiser, controle total sobre o andamento das associaes; no estilo UDP, abrir associaes com nmero de uxos, timeout de associao etc. escolhidos pela aplicao; no estilo UDP, fechar associaes manualmente sem recorrer a sctp_peeloff().

No estilo UDP o uso de sendto() e recvfrom() pode criar ambiguidades, pois estes identicam a associao pelo endereo e porta do terminal remoto, o que pode ser ambguo no caso de associaes com multicaminhos. No I/O avanado, cada associao tem um identicador opaco de 32 bits, o que resolve o problema. (Esse problema no diz respeito ao estilo TCP pois neste o soquete quem identica univocamente a associao.) O I/O avanado tambm evita a destruio da atomicidade caso a mensagem seja maior que o buffer de recepo oferecido pelo aplicativo. A entrega parcial de mensagem sinalizada ao aplicativo, que pode obter e tratar os diversos fragmentos. Flags de mensagem A coleta de dados auxiliares recebe/entrega uma varivel em forma de bitmap, que em SCTP pode conter os seguintes ags:
MSG_NOTIFICATION MSG_EOR MSG_CTRUNC MSG_EOF Buffer de transmisso/recepo contm um evento e no dados Mensagem foi inteiramente entregue, ou ltimo fragmento foi entregue Dados auxiliares truncados e perdidos (buffer insuciente) Indica que a associao deve ser fechada (sendmsg())

109

Mensagens auxiliares As mensagens auxiliares so mandadas ou recebidas em paralelo com dados teis. Pode haver diversas mensagens auxiliares, de diversos protocolos diferentes (e.g. tanto a camada IP quanto SCTP entregam mensagens auxiliares referentes a uma mensagem da aplicao). As mensagens prprias do SCTP so apenas duas: SCTP_INIT Essa mensagem serve apenas para criar associaes explicitamente atravs de sendmsg(), e nunca recebida. A estrutura da mensagem :

struct sctp_initmsg { uint16_t sinit_num_ostreams; uint16_t sinit_num_instreams; uint16_t sinit_max_attempts; uint16_t sinit_max_init_timeo; }

sinit_num_ostreams sinit_num_instreams sinit_max_attempts sinit_max_init_timeo

Nmero de uxos de transmisso desejado. Nmero mximo de uxos de recepo aceito pela aplicao. Nmero mximo de tentativas para estabelecer a associao. Timeout para o estabelecimento da associao.

SCTP_SNDRCV Essa mensagem acompanha mensagens de dados teis, tanto na transmisso quanto na recepo. A cada mensagem de dados transmitida ou recebida, corresponde uma e apenas uma mensagem auxiliar SCTP_SNDRCV. A estrutura da mensagem :

struct sctp_sndrcvinfo { uint16_t sinfo_stream; uint16_t sinfo_ssn; uint16_t sinfo_flags; uint32_t sinfo_ppid; uint32_t sinfo_context; uint32_t sinfo_timetolive; uint32_t sinfo_tsn;

110

uint32_t sinfo_cumtsn; sctp_assoc_t sinfo_assoc_id; };

sinfo_stream sinfo_ssn sinfo_ags

Nmero do uxo de transmisso ou recepo. Nmero seqencial da mensagem no uxo (apenas recepo). Mapa de bits com os seguintes valores possveis: MSG_UNORDERED: mensagem urgente (no ordenada);

MSG_ADDR_OVER: requisita implementao para usar o endereo especicado em sendmsg()/sendto() ao invs do endereo primrio;

MSG_ABORT: Faz a associao ser abortada; MSG_EOF: Faz a associao ser fechada (shutdown); os dados em la dos
dois lados sero transmitidos antes do fechamento.

sinfo_ppid

Identicador de protocolo (passado e interpretado pelas aplicaes, no utilizado pelo SCTP em si).

sinfo_context sinfo_timetolive

Valor passado pela aplicao, que ser devolvido em caso de erro de transmisso. Tempo de vida da mensagem em ms. Se a mensagem vencer ainda na la de transmisso, no ser mais mandada. O valor zero signica tempo de vida innito. Na extenso PR-SCTP, o tempo de vida muda ligeiramente de semntica; a mensagem no ser mais transmitida mesmo que j tenha havido tentativas de transmisso.

sinfo_tsn sinfo_cumtsn sinfo_assoc_id

Valor do TSN do trecho de dados (apenas recepo). Valor do TSN cumulativo atual (apenas na recepo de mensagens urgentes). Identicador (handle) da associao.

O tipo sctp_assoc_t um handle de 32 bits opaco (no deve ser interpretado como nmero). Toda mensagem, seja de dados, seja de evento, usa esse handle para identicar unicamente cada associao. A aplicao usuria do estilo UDP avanado deve prestar ateno s mensagens de criao de associaes, e anotar o handle para futuras referncias. Eventos Os eventos so mensagens especiais, lidas/gravadas no prprio buffer de transmisso/recepo de dados. Como so devidamente sinalizadas por MSG_NOTIFICATION e nunca ocorrem juntamente com dados da aplicao, podem ser interpretadas sem ambiguidade. Todos os eventos tm um cabealho em comum em sua estrutura:

111

struct { uint16_t sn_type; uint16_t sn_flags; uint32_t sn_length; } sn_header;

Atravs do valor de sn_type, sabe-se o tipo de evento e implicitamente a estrutura de dados correspondente a ele. Os tipos de evento possveis so:
SCTP_ASSOC_CHANGE SCTP_PEER_ADDR_ CHANGE SCTP_REMOTE_ERROR Sinaliza que uma associao foi aberta ou fechada. O endereo que parte de uma associao aberta sofreu mudana de estado (falha ou reabilitao). O terminal remoto retornou um erro operacional, por conta de um tipo de trecho no suportado. Inclui o trecho que causou o erro. SCTP_SEND_FAILED Mensagem no pde ser enviada. Inclui a estrutura sctp_sndrecvinfo que iria ser enviada. SCTP_SHUTDOWN_ EVENT SCTP_ADAPTION_ INDICATION SCTP_PARTIAL_ DELIVERY_EVENT Entrega parcial abortada pode indicar uma associao que est para ser abortada. O terminal remoto remeteu um pacote SHUTDOWN. No se pode mandar mais dados para essa associao. O terminal remoto requisitou uma determinada camada de adaptao.

Opes de soquete (setsockopt) Toda opo de soquete envolve a passagem de um valor inteiro ou de uma estrutura, conforme a necessidade.
SCTP_RTOINFO Alterao dos parmetros de RTO (timeout de retransmisso). A implementao deve impor limites a usurios no-privilegiados na alterao desses parmetros. SCTP_ASSOCINFO Obteno e alterao de diversos parmetros da associao e do terminal remoto e.g. janela de transmisso e recepo SCTP_INITMSG Alteraes dos parmetros padro utilizados em associaes automaticamente criadas SO_LINGER Utilizado em soquetes estilo TCP para abortar uma conexo ao invs do SHUTDOWN normal.

112

SCTP_NODELAY

Ligar/desligar o algoritmo Nagle. No caso do SCTP, esse algoritmo tem a funo de empacotar diversos trechos pequenos em um datagrama. Com o Nagle desligado, todo trecho mandado assim que solicitado.

SO_RCVBUF SO_SNDBUF SCTP_AUTOCLOSE

Tamanho da janela de recepo (rwnd). Tamanho do buffer de transmisso. (Apenas para soquetes estilo UDP.) Controla o tempo de fechamento automtico de associaes em desuso, em segundos. O valor zero desliga o fechamento automtico.

SCTP_SET_PRIMARY_ ADDR SCTP_SET_PEER_ PRIMARY_ADDR SCTP_SET_ADAPTION_ LAYER

Solicita que o terminal remoto considere o endereo passado como o primrio. (Opcional depende da extenso AddIP) Solicita que o sistema local use o endereo passado como o endereo primrio do terminal remoto. (Opcional depende da extenso AddIP) Requisita que o sistema local emita o trecho adaption layer indication, com o valor especicado, para novas associaes. O terminal remoto receber a mensagem SCTP_ADAPTION_INDICATION.

SCTP_DISABLE_ FRAGMENTS

Se habilitado, nenhuma mensagem ser fragmentada em diversos trechos, e tem de caber no PMTU sob pena de um erro ser retornado aplicao.

SCTP_SET_PEER_ ADDR_PARAMS SET_DEFAULT_SEND_ PARAM SCTP_SET_EVENTS

Manipulao dos heartbeats para os endereos remotos.

Parmetros padro da estrutura sctp_sndrcvinfo para as remessas que utilizem a interface simplicada sendto(). Permite especicar os eventos que a aplicao est interessada em receber.

SCTP_I_WANT_ MAPPED_ V4_ ADDR SCTP_MAXSEG

Se esta opo estiver habilitada e o soquete for IPv6, os endereos IPv4 sero representados como mapeados em IPv6. Do contrrio, recebe tanto endereos IPv4 quanto IPv6. Limita o tamanho mximo de qualquer trecho. Trechos maiores sero fragmentados.

SCTP_STATUS SCTP_GET_PEER_ ADDR_INFO

(somente leitura) Obtm estado e informaes sobre uma associao. Obtm informaes sobre um endereo especco do terminal remoto.

Atrelamento (bind) das interfaces de rede O aplicativos-clientes TCP (e alguns aplicativos-clientes UDP) optam geralmente em no chamar a funo bind(). O sistema decide pela tabela de roteamento qual a

113

interface de rede mais prxima do destino; e atribui uma porta de origem efmera, aleatria, que no conite com outras conexes e com servios bem conhecidos. Na maioria dos clientes UDP, e na quase totalidade de servidores de TCP e UDP, mais comum chamar-se bind() com o pseudo-endereo INADDR_ANY (IPv4) ou in6addr_any (IPv6), que atrela o soquete a todas as interfaces de rede da mquina. Porm, no caso do SCTP, no chamar bind(), ou cham-lo com INADDR_ANY ou in6addr_any tem uma semntica diferente: facultada implementao utilizar automaticamente todas as interfaces de rede disponveis para ns de multicaminhos. O sistema pode optar em usar todas as interfaces, ou um subconjunto timo. STEWART et al. (2004a) no dene o que timo, ou seja, no dene os critrios de escolha das interfaces de rede; isso ca a cargo da implementao. Essa mudana de semntica vale tanto para clientes como para servidores. O desenvolvedor deve car atento para eventuais problemas com redes com endereos privados (e.g. 10.0.0.0/8) ou invlidos. O livro de STEWART & XIE (2002) sugere que as implementaes permitam ao administrador do sistema denir as faixas proibidas para multicaminhos. As faixas proibidas padro seriam as faixas de endereamento privado para IPv4, e as faixas de escopo local para IPv6. A funo bind() suporta apenas um endereo (ou absolutamente todos, via INADDR_ANY), e no permitido chamar bind() repetidas vezes para especicar vrios endereos. Se uma aplicao SCTP quer utilizar um subconjunto especco de interfaces de rede para multicaminhos, deve usar a funo sctp_bindx(), que faz as vezes de bind() e aceita uma lista de endereos. No protocolo UDP, que no tem suporte a multicaminhos embutido, as aplicaes contornam essa limitao criando um soquete para cada interface de rede. Um aplicativo servidor SCTP que deseja atender em todas as interfaces de rede, mas no queira usar multicaminhos, deve adotar a mesma estratgia. Relao de interfaces completamente novas Quase todas as novas funes tm relao com o suporte a multicaminhos.

sctp_peeloff()

No estilo UDP, separa do soquete genrico uma determinada associao, dando-lhe um manipulador de arquivo exclusivo

sctp_bindx()

Uma verso de bind() que permite especicar uma lista de endereos, para controle no do multicaminhos.

114

sctp_connectx()

Uma verso de connect() que permite especicar uma lista de endereos, para controle no do multicaminhos.

sctp_getpaddrs()

Obtm todos os endereos remotos de uma associao. Retorna uma matriz dinamicamente alocada.

sctp_freepaddrs() sctp_getladdrs()

Libera da memria a matriz retornada por sctp_getpaddrs(). Obtm todos os endereos locais de uma associao. Retorna uma matriz dinamicamente alocada.

sctp_freeladdrs() sctp_sendmsg()

Libera da memria a matriz retornada por sctp_getladdrs(). Funo oferecida opcionalmente como alternativa a sendmsg(). No deve ser usada para associaes multicaminhos.

sctp_recvmsg()

Funo oferecida opcionalmente como alternativa a recvmsg(). No deve ser usada com associaes multicaminhos.

sctp_opt_info()

Certas chamadas getsockopt() SCTP implicam em passagem de informaes atravs do buffer destinado ao retorno. Em algumas implementaes, essa passagem de informaes no permitida. A chamada sctp_opt_info() deve ento ser usada.

Macros Algumas macros identicam a presena do protocolo SCTP e suas extenses. O recurso existe se a macro denida e tem o valor 1.
HAVE_SCTP HAVE_KERNEL_SCTP Existe implementao do SCTP no sistema. A implementao do SCTP est no kernel e pode ser acessada pela interface BSD Sockets. (Uma implementao user-level tem de ser acessada por funes de biblioteca). HAVE_SCTP_PRSCTP HAVE_SCTP_ADDIP HAVE_SCTP_ CANSET_PRIMARY HAVE_SCTP_SAT_ NETWORK_CAPABILITY HAVE_SCTP_MULTIBUF No estilo UDP, implementa um buffer por associao ao invs de um buffer nico. O buffer nico pode causar problemas em aplicaes que remetem quantidade excessiva de dados sem aguardar conrmao. HAVE_SCTP_ NOCONNECT No estilo TCP, permite que a funo sendto() inicie automaticamente a associao. A extenso de suporte a redes por satlite suportada. A extenso PRSCTP suportada. A extenso AddIP suportada. A extenso de mudana dinmica do IP primrio suportada.

115

Fatores determinantes na escolha do estilo TCP ou UDP O estilo UDP fornece mais ferramentas de controle da associao. Aplicaes de sinalizao telefnica, que motivaram a criao do SCTP, tm no estilo UDP uma interface mais apropriada. O estilo TCP facilita muito a adio de suporte ao SCTP em aplicaes que j usam o protocolo TCP. Ele tambm fornece uma interface mais conhecida e mais fcil de usar, permitindo que o desenvolvedor mantenha inalterado o uso de I/O bloqueante, select(), poll(), subprocessos, threads, passagem de soquetes para outros processos etc. A adaptao de um aplicativo existente ao estilo UDP muito mais difcil, e o suporte simultneo de TCP e SCTP impe duplicao de cdigo. O estilo UDP claramente voltado para aplicativos novos, e que usem exclusivamente SCTP como transporte. Para a maioria das aplicaes em uso na Internet, o nvel de controle oferecido pelo estilo UDP no necessrio, sendo suciente a interface apresentada pelo estilo TCP, que d acesso aos recursos interessantes do SCTP e.g. multicaminhos, uxos e mensagens com prazo de validade. O estilo UDP faz uso de um nico soquete para todas as associaes, o que alivia as aplicaes com grande nmero de associaes simultneas. No entanto, a substituio de select() por poll() e /dev/epoll permite tambm ao estilo TCP suportar de forma escalvel um nmero virtualmente ilimitado de soquetes. O estilo UDP no permite o uso convel de select()/poll() para transmisso; necessrio usar I/O no bloqueante. Aplicaes que transmitam contedos de grande volume e sem estrutura (e.g. arquivos) so muito mais fceis de implementar com I/O bloqueante, e tendem a preferir o estilo TCP. Associaes que faam uso de conabilidade parcial (como por exemplo multimdia em tempo real) utilizaro mais provavelmente o estilo UDP. O I/O no-bloqueante adequado para servidores de contedo multimdia.

Referncias Bibliogrcas
AGGARWAL, Avnish et al. RFC 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. IETF Network Working Group, 1987. AGGARWAL, Avnish et al. RFC 1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specications. IETF Network Working Group, 1987. ALBITZ, Paul; LIU, Cricket. DNS and BIND. 2.ed. OReilly, 1997. ALLMAN, M.; PAXSON, V.; STEVENS, W. TCP Congestion Control. IETF Network Working Group, 1999. ARIAS-RODRIGUEZ, Ivn. Stream Control Transmission Protocol The design of a new reliable transport protocol for IP networks. Helsinki University of Technology, Electrical and Communications Engineering Department. Networking Laboratory 2002/02/12. BELLOVIN, S. M.; IOANNIDIS, J.; KEROMYTIS, A. D. et al. On the use of SCTP with IPSec (draft-ietf-ipsec-sctp-06.txt). IETF Network Working Group, 2003. BERNSTEIN, Dan J. SYN Cookies. http://cr.yp.to/. 1997. CAMARILLO, Gonzalo. SIP Demystied. McGraw-Hill, 2002. COENE, L. RFC 3257 Stream Control Transmission Protocol Applicability Statement. IETF Network Working Group, 2002. CUSTDIO, Felipe. Segurana em Computao. UFSC/PPGCC, 2002. DANTAS, Mrio. Tecnologia de rede de comunicao e computadores. Axcel Books, 2002. ECKSTEIN, Robert; COLLIER-BROWN, David; KELLY, Peter. Using SAMBA. OReilly, 2000. FIELDING, R.; GETTYS, J.; MOGUL, J. et al. RFC 2616 Hypertext Transfer Protocol HTTP/1.1. IETF Network Working Group, 1999. FINLAYSON, R. RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. IETF Network Working Group, 2001. FLOYD, Sally; HANDLEY, Mark; KOHLER, Eddie. Problem Statement for DCCP. IETF Network Working Group, 2002. GEORGE, Tom; BIDULOCK, Brian; DANTU, Ram et al. SS7 MTP2-User Peerto-Peer Adaptation Layer. IETF Network Working Group, 2003. HOFFMAN, D.; FERNANDO, G.; GOYAL, V. et al. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video. IETF Network Working Group, 1998.

117

JUNGMAIER, A.; RATHGEB, E. P.; SCHOPP, Michael et al. SCTP A Multi-link End-to-end Protocol for IP-based Networks. AE International Journal of Electronics and Communications. 55 (2001) No. 1, 46-54, 2001. JUNGMAIER, A.; RESCORLA, E.; TUEXEN, M. RFC 3436 Transport Layer Security over Stream Control Transmission Protocol. IETF Network Working Group, 2002. KAME: http://www.kame.net. Stio da implementao do SCTP e do IPSEC no FreeBSD. KANG, Sukwoo; FIELDS, Mattew. Experimental Study of the SCTP compared to TCP. Texas A&M University. Computer Communications and Network Fall, 2003. KARN, P.; SIMPSON, W. RFC 2522 Photuris: Session-Key Management Protocol. IETF Network Working Group, 1999. KRAWCZYK, H.; BELLARE, M.; CANETTI, R. RFC 2104 HMAC: KeyedHashing for Message Authentication. IETF Network Working Group, 1999. LEIGHTON, Luke Kenneth Casson. DCE/RPC over SMB. Samba and Windows NT Domain Internals. MTP, 2002. LEWIS, Bil; BERG, Daniel J. Multithreaded Programming with Pthreads. Sun Microsystems Press, 1998. LKSCTP: http://lksctp.sourceforce.net. Stio do LK-SCTP (Kernel-Level SCTP), a implementao do SCTP no Linux. MAZZOLA, Vitrio Bruno. UFSC/PPGCC, 2002. Arquitetura de Redes de Computadores.

MENTAT. http://www.mentat.com/xtp/xtp-overview.html. Site da empresa Mentat sobre o protocolo XTP. MORNEAULT, K.; RENGASAMI, S.; KALLA, M. et al. RFC 3057 ISDN Q.921-User Adaptation Layer. IETF Network Working Group, 2001. MORNEAULT, K.; DANTU, R.; SIDEBOTTOM, G. et al. RFC 3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) User Adaptation Layer. IETF Network Working Group, 2002. NAGLE, John. RFC 896 Congestion Control in IP/TCP Internetworks. IETF Network Working Group, 1984. ONG, L.; RYTINA, I.; GARCIA, M. et al. RFC 2719 Framework Architecture for Signaling Transport. IETF Network Working Group, 1999. ONG, L.; YOAKUM, J. RFC3286 An Introduction to the Stream Control Transmission Protocol (SCTP). IETF Network Working Group, 2002. POSTEL, J.; REYNOLDS, J. RFC 959 File Transfer Protocol (FTP). IETF Network Working Group, 1985;

118

RAJAMANI, Rajesh; KUMAR, Sumit; NIKHIL, Gupta. SCTP versus TCP: Comparing the performance of transport protocols for Web trafc. Computer Sciences Department, University of Wisconsin-Madison, 2002. RAMAKRISHNAN, K.; FLOYD, S.; BLACK, D. RFC 3168 The Addition of Explicit Congestion Notication (ECN) to IP. IETF Network Working Group, 2001. RIVUS: http://rivus.sourceforge.net. Stio da implementao do SCTP em sistema operacional BSD, com extenso de Load Sharing. RUSSELL, Travis. Signaling System #7. 4. ed. McGraw-Hill, 2002. SCHULZRINNE, H.; CASNER, S.; FREDERICK, R. et al. RFC 1889 RTP: A Transport Protocol for Real-Time Applications. IETF Network Working Group, 1996. SCTP.ORG: http://www.sctp.org. Stio dos principais autores do SCTP. SHANNON, Claude. A Mathematical Theory of Communication. The Bell System Technical Journal, Vol. 27, pag. 379-423, 623-656, Julho/Outubro de 1948. SHREMMINGER: http://developer.osdl.org/shremminger/netem/example.html. Emulating wide area network delays. Stio da ferramenta de simulao de rede Netem. SIDEBOTTOM, G.; MORNEAULT, K.; PASTOR-BALBAS, J. RFC 3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) User Adaptation Layer (M3UA). IETF Network Working Group, 2002. STEVENS, Richard W. RFC 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms. IETF Network Working Group, 1997. STEVENS, Richard W. TCP/IP Illustrated Volume 1. The Protocols. AddisonWesley, 1994. STEVENS, Richard W.; Fenner, Bill; Rudoff, Andrew M. Unix Network Programming Volume 1. Networking APIs: Sockets and XTI. 3.ed. Prentice-Hall, 2004. STEWART, R.; XIE, Q.; MORNEAULT, K. et al. RFC 2960 Stream Control Transmission Protocol. IETF Network Working Group, 2000. STEWART, Randall R.; XIE, Qiaobing. Stream Control Transmission Protocol (SCTP). Addison-Wesley, 2002. STEWART, R.; RAMALHO, M.; XIE, Q. et al. SCTP Partial Reliability Extension (draft-stewart-tsvwg-prsctp-03.txt). IETF Network Working Group, 2003. STEWART, R.; RAMALHO, M.; XIE, Q. et al. Stream Control Transmission Protocol (SCTP) Dynamic Address Reconguration. IETF Network Working Group, 2003. STEWART, R., ONG, L., ARIAS-RODRIGUEZ, I. et al. Stream Control Transmission Protocol (SCTP) Implementers Guide. IETF Network Working Group, 2003. STEWART, R.; XIE, Q.; YARROLL, L. et al. Sockets API Extensions for Stream Control Transmission Protocol SCTP. IETF Network Working Group, 2004.

119

STEWART, R; RAMALHO, M. et al. RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension. IETF Network Working Group, 2004. STONE, J.; STEWART, R.; OTIS, D. RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change. IETF Network Working Group, 2002. TANENBAUM, Andrew S. Redes de computadores. 4.ed. Rio de Janeiro: Campus, 2002. USAGI: http://www.linux-ipv6.org. Stio do projeto USAGI, que implementa o IPv6 no Linux, coligado com o projeto KAME. WILLRICH, Roberto. Sistemas multimdia distribudos. UFSC/PPGCC, 2002. XIE, Q.; STEWART, R.; SHARP, C. et al. SCTP Unreliable Data Mode Extension (draft-ietf-tsvwg-usctp-00.txt). IETF Network Working Group, 2001.

A Este trabalho foi editado no LYX e tipografado pelo LTEX .