IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 3, JUNE 2007
171
Avaliação de Desempenho do Protocolo SCTP
no Linux
E. Pfützenreuter, L. F. Friedrich
Resumo— O SCTP (Stream Control Transmission Protocol) é
um protocolo da pilha TCP/IP, originalmente concebido para
transporte de mensagens de sinalização telefônica. Este artigo
exibe uma série de testes de desempenho realizados com a
implementação Linux Kernel SCTP (LK-SCTP).
Palavras-chave— Desempenho de sistemas de comunicação,
Internet, Protocolos, Telefonia
I.
INTRODUÇÃO
O SCTP (Stream Control Transmission Protocol) é um
protocolo de transporte relativamente novo, derivado do
trabalho de dois pesquisadores, Randall Stewart e Qiaobing
Xie, e refinado pelo comitê SIGTRAN (SIGnalling
TRANsport) da IETF. O objetivo desse comitê era encontrar
ou criar um protocolo adequado à transmissão sobre TCP/IP
de mensagens de sinalização telefônica. Protocolos existentes
como TCP e UDP foram julgados inadequados para a tarefa, o
que levou à criação do SCTP.
A RFC 2960 [1] contém a definição formal do protocolo.
Tal qual TCP, o SCTP é um protocolo confirmado ponto-aponto, mas com diversos recursos adicionais, entre eles:
• transporte confirmado e ordenado de mensagens
indivisíveis, e não octetos como em TCP. As mensagens são
sempre entregues atomicamente à aplicação;
• múltiplos fluxos de transmissão de mensagens, que
funcionam como subconexões. A perda de uma mensagem
afeta apenas o respectivo fluxo, evitando o Head-of-Line
Blocking que ocorre em TCP;
• as mensagens são normalmente entregues em ordem, mas
essa garantia pode ser relaxada seletivamente, para mensagens
urgentes ou quando a ordem for irrelevante;
• se a extensão PR–SCTP (Partial Reliability SCTP) [2]
estiver implementada, também a garantia de entrega pode ser
dispensada, o que permite o uso de SCTP em multimídia de
tempo real;
• maior resistência a corrupção acidental de dados e a
ataques spoof e SYN flood.
Manuscrito submetido em 01/Nov/2005, revisado em 25/Jul/2006.
Elvis Pfützenreuter é pesquisador no Instituto Nokia de Tecnologia -INdT. E-mail: [email protected].
Dr. Luis Fernando Friedrich é professor no Departamento de
Informática e Estatística -- Universidade Federal de Santa Catarina. E-mail:
[email protected].
• aproveitamento automático de múltiplas conexões de
rede para fins de redundância. Se o caminho primário falhar, a
comunicação alterna para um caminho secundário de forma
transparente à aplicação.
O controle de congestionamento do SCTP utiliza os
mesmos algoritmos do TCP que já são largamente conhecidos
e testados e asseguram lealdade entre conexões TCP e SCTP
paralelas.
Os documentos [3] e [4] enumeram os recursos do SCTP,
fazem uma análise da aplicabilidade e tratam da interação do
SCTP com outras tecnologias e.g. roteadores NAT.
Este artigo exibe uma série de testes de desempenho
realizados sobre a implementação LK–SCTP (Linux Kernel
SCTP) [5], disponível no Linux a partir da versão 2.4. A
versão utilizada nos testes foi a 2.6.10.
O projeto foi motivado pela escassez à época de testes
elaborados tanto com o protocolo SCTP quanto sobre a
implementação LK–SCTP. Ainda mais escassos são exemplos
de programas que utilizam SCTP.
A grande maioria dos testes comparou SCTP com TCP. O
SCTP é um protocolo ponto-a-ponto confirmado tal qual TCP.
Na maioria das aplicações em que se cogitaria usar SCTP, a
escolha ficaria entre SCTP e TCP. Na maioria dos protocolos
de aplicação, o SCTP é um substituto "drop in" para TCP; esta
substituição traz no mínimo vantagens de segurança, e
possivelmente vantagens de desempenho, pois o controle de
erros do SCTP é mais sofisticado.
Em quase todos os testes, tanto o Linux quanto o LK–
SCTP foram utilizados em suas configurações default, sem
qualquer otimização. Presume-se que a maioria dos usuários
use seu sistema da mesma forma, e que uma configuração
default sub-ótima provavelmente será percebida como um
problema inerente ao protocolo.
Os testes envolveram a criação de diversos cenários típicos
de rede. Foram utilizadas redes Ethernet de 100Mbps e
10Mbps, e as demais características de redes WAN típicas
(e.g. perda e latência) foram simuladas com recursos do
próprio Linux, como o filtro de pacotes IPTables [6] e a
disciplina de tráfego Netem [7].
O código-fonte dos softwares utilizados nos testes pode ser
encontrado em [8], bem como os resultados de outros testes.
II.
TESTES DE PERFORMANCE BRUTA
Os testes de performance bruta comparam SCTP frente a
TCP nos quesitos de vazão e latência. As mensagens SCTP
172
são entregues com todas as garantias através de um único
fluxo.
A vazão é a métrica mais facilmente percebida pelo usuário
final e certamente é importante em diversas aplicações, como
transferência de grandes objetos via rede. O teste de vazão
simplesmente exercita a transferência de dados full-duplex.
A latência costuma ser negligenciada como medida de
desempenho, embora seja tão importante quanto a vazão. O
teste consiste em cronometrar o tempo de uma transação
cliente/servidor simulada, com uma mensagem de requisição e
uma mensagem de resposta.
Para determinar início e fim de cada mensagem nos testes
de latência, foi necessário empilhar ao TCP um protocolo de
aplicação muito simples, denominado neste trabalho de
TCPM. O TCPM também foi empilhado ao TCP em parte dos
testes de vazão, no intuito de torná-los mais leais, pois
equipara a sobrecarga de separação de mensagens em TCP e
SCTP.
O teste de desempenho em loopback (conexões entre
processos da mesma máquina) foi executado também com os
soquetes UNIX, para fins de comparação. Tais testes
aparecem nas figuras como "unix" (soquete UNIX puro) e
"unixm" (TCPM empilhado sobre soquete UNIX).
A Figura 1 mostra que o TCP tem vazão maior que SCTP
em loopback, afinal TCP tem sobrecarga muito menor. No
entanto, quando o protocolo de separação de mensagens
TCPM foi utilizado sobre soquetes UNIX e TCP, seus
respectivos desempenhos assemelharam-se a SCTP.
IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 3, JUNE 2007
Figura 2: Latência em conexões loopback
Concluiu-se que o desempenho menor do SCTP é em parte
inerente ao protocolo, cuja sobrecarga é maior mesmo sem
CRC-32c, e em parte pelo fato da implementação ser menos
otimizada que TCP.
Numa rede Ethernet 100Mbps padrão, a vazão SCTP é
bastante inferior a TCP para mensagens pequenas, conforme a
Figura 3. Uma análise do tráfego de rede mostrou que o LK–
SCTP acomoda uma mensagem por datagrama, quando
poderia acomodar várias – otimização denominada message
bundling, que é de implementação opcional, de acordo com
[1].
Figura 3: Vazão em rede 100Mbps
Figura 1: Vazão em conexões loopback
Em mensagens grandes, a vazão do soquete UNIX é
previsivelmente muito maior que TCP. Curiosamente, a vazão
do soquete UNIX foi menor que TCP em mensagens pequenas
(até 100 bytes).
A latência do SCTP em loopback foi duas vezes maior que
TCPM (Figura 2). Diversos fatores foram verificados para
explicar o resultado. O somatório de verificação CRC-32c
(que empresta ao SCTP grande resistência a corrupção de
dados) costuma ser apontado como sobrecarga importante.
Experimentou-se o desligamento do CRC-32c, mas o aumento
de desempenho não foi sensível. A biblioteca de auxílio do
LK–SCTP também não introduz sobrecarga sensível em
relação ao uso direto de chamadas de sistema.
Conforme o tamanho da mensagem aproxima ou excede o
tamanho do datagrama Ethernet, a vazão do SCTP aproximase do TCP, e a vazão de ambos passa a ser limitada apenas
pela banda da rede.
A latência do SCTP na rede 100Mbps padrão é apenas um
pouco maior que TCP, conforme pode ser visto na Figura 4.
Os mesmos fatores que prejudicaram a latência SCTP no
loopback continuam presentes nesse teste, mas ficam
parcialmente mascarados pela latência da rede.
PFÜTZENREUTER AND FRIEDRICH : PERFORMANCE EVALUATION OF SCTP PROTOCOL
Figura 4: Latência em rede 100Mbps
Em redes 100Mbps com perda variável de pacotes, a vazão
do SCTP teve um desempenho razoável (Figura 5), inclusive
ultrapassando TCP em perdas moderadas (entre 1% e 10%).
Tal resultado deve-se ao SACK (Selective Acknowledgement)
aprimorado do protocolo SCTP.
Figura 5: Vazão em rede 100Mbps com perdas
Já a latência do SCTP piora muito numa rede 100Mbps
com perdas, conforme mostra a Figura 6. A causa do mau
desempenho é uma configuração do LK–SCTP – o RTO
(retransmission timeout) mínimo padrão, cujo default é de 1
segundo, conforme recomendado em [1].
RTO é o tempo que um pacote perdido leva para ser
retransmitido. Como a latência de uma rede Ethernet é menor
que 1ms, o RTO de 1 segundo faz o SCTP esperar 1000 vezes
mais que o necessário para retransmitir um pacote perdido,
com a conseqüente quebra de desempenho.
Além disso, o RTO é multiplicado por 2 a cada
retransmissão fracassada (sobe exponencialmente com perdas
repetidas). Numa rede com grandes perdas, o RTO pode
atingir valores muito altos. Se o RTO inicial é muito alto, a
conexão pode estolar completamente.
Esses problemas não foram observados no teste de vazão
(Figura 5), pois naquele os pacotes são transmitidos
continuamente em ambas as direções, o que favorece a
detecção rápida das perdas pelo SACK.
TCP e SCTP têm ambos problemas de desempenho em
redes com perdas, mas especificamente no Linux o TCP
desempenha melhor que SCTP, pois o RTO mínimo do TCP
Linux é de apenas 200ms, violando propositadamente as
RFCs de controle de congestionamento no intuito de extrair
desempenho aceitável. O LK–SCTP segue rigorosamente sua
RFC e é prejudicado frente ao TCP.
O TCP do FreeBSD emprega RTO mínimo ainda mais
baixo: 3 tiques do relógio do escalonador, o que redunda em
30ms em versões mais antigas do FreeBSD e 3ms a partir do
FreeBSD 6.
Conforme o RTO mínimo do LK–SCTP é reduzido por
meio da interface /proc/sys/net/sctp, o SCTP passa a
desempenhar proporcionalmente melhor, naturalmente
ultrapassando TCP com RTO mínimo = 1ms (menor valor
possível).
Interessante notar que o RTO inicial do TCP do Linux é de
3000ms, em conformidade com suas RFCs e mais alto que o
do SCTP. Esse parâmetro do TCP não é ajustável em tempo
de execução no Linux, mas existem patches para o kernel que
manipulam esses valores, visando justamente melhorar o
desempenho do TCP sobre canais com altas perdas e baixa
latência.
Em redes com latência mais elevada, o RTO mínimo
padrão do LK–SCTP fica num patamar menos inadequado, e
seu desempenho tende a ficar próximo do TCP. As figuras 7 e
8 ilustram essa observação.
Figura 7: Vazão em rede 10Mbps com perdas
Figura 6: Latência em rede 100Mbps com perdas
173
174
IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 3, JUNE 2007
Os softwares HTTP tiveram, entre todos os softwares
trabalhados em [8], a adaptação mais completa e trabalhosa
para SCTP. Uma métrica empírica do impacto das
modificações é o número de linhas adicionadas ou alteradas.
Tomando por base o thttpd, cujo código-fonte principal (sem
documentação ou módulos extras) possui 14268 linhas, a
simples troca do transporte de TCP para SCTP implicou 35
linhas alteradas ou adicionadas (0,2% do total). A adaptação
mais completa, que permitiu o uso de diversos fluxos SCTP,
exigiu 639 linhas alteradas ou adicionadas (4,4% do total).
Figura 8: Latência em rede 10Mbps com perdas
III. TESTES COM APLICAÇÕES REAIS
Os testes a seguir fizeram uso de protocolos de aplicação
comumente utilizados em TCP/IP e na Internet, bem como
adaptação de implementações reais.
A.
HTTP
O método de teste para HTTP é a transmissão de arquivos
de tamanho fixo, e o critério de avaliação do desempenho é a
vazão em KBytes/s.
Do lado servidor, foi escolhido e adaptado o programa
thttpd [9] versão 2.25b. Já do lado cliente, foi adotado um
software específico para testes de desempenho, o httperf [10].
Uma adaptação do Mozilla versão 1.6, sem suporte a múltiplos
fluxos, também foi feita, mas foi usada apenas como
ferramenta de teste.
Para cada cenário de rede, foram executados quatro testes:
TCP, SCTP com um fluxo, SCTP com 10 fluxos e SCTP com
100 fluxos por conexão. Cada fluxo transporta uma transação
HTTP. O protocolo HTTP teve de ser adaptado em alguns
detalhes para funcionar sobre diversos fluxos de uma mesma
conexão; o documento [8] contém um rascunho de adaptação
HTTP/SCTP.
Nesse teste, o SCTP superou o TCP nos cenários com
múltiplos fluxos, conforme mostram as Figuras 10 e 9. Usar
vários fluxos por conexão SCTP dilui os custos de
abertura/fechamento de conexão, em particular quando o
tamanho dos arquivos trafegados é pequeno e/ou a latência da
rede aumenta.
Figura 9: HTTP sobre rede de 1Mbps
Figura 10: HTTP sobre rede de 100Mbps
B.
Áudio MP3 sobre RTP
O teste com o protocolo RTP (Real Time Protocol) [11]
mede a capacidade de entregar satisfatoriamente um conteúdo
multimídia – áudio em formato MP3, taxa de 192Kbps –
através de uma rede com banda estreita e perdas de pacotes. A
definição de satisfatório é, nesse teste, subjetiva, pois é
apurada com base na qualidade de áudio percebida pelo
ouvinte.
No teste, o desempenho do SCTP é comparado com UDP.
Como o fluxo transmitido é tolerante a perdas, também foi
possível testar a extensão PR–SCTP. O aplicativo poc [12],
utilizado nos testes, implementa tanto clientes quanto
servidores de áudio MP3, usando o protocolo RTP e vários
encapsulamentos para MP3.
Como o formato MP3 não foi desenvolvido para
transmissão com perdas, é necessário encapsulá-lo de forma a
minimizar o impacto das perdas. Os testes experimentaram os
encapsulamentos RFC 2250 [13], RFC 3119 [14] e Forward
Error Correction (FEC [12]), este último desenvolvido pelo
autor do poc.
Para cada encapsulamento, uma grade de cenários de rede
foi criada, pela variação da banda passante e da perda de
pacotes. A latência da rede foi fixada em 30ms para todos os
cenários (portanto, o RTT (round-trip time) é de 60ms). Em
cada grade, foram testados os transportes UDP, SCTP e PR–
SCTP.
Os gráficos do teste (Figuras 11, 12 e 13) plotam as linhas
limítrofes de áudio satisfatório para cada transporte. A área
delimitada acima e à esquerda de cada linha cobre os cenários
de rede nos quais o áudio passou aceitavelmente. A área
abaixo e à direita da linha cobre os cenários em que o áudio
PFÜTZENREUTER AND FRIEDRICH : PERFORMANCE EVALUATION OF SCTP PROTOCOL
falhou.
Em SCTP, as mensagens foram transmitidas todas como
urgentes, ou seja, sem garantia de entrega ordenada. No PR–
SCTP, além de desordenadas, as mensagens têm prazo de
validade fixo em 200ms, consoante com o RTT de 60ms. As
mensagens não transmitidas no prazo são descartadas,
portanto, diferente do SCTP padrão, elas não têm garantia de
entrega.
A vantagem teórica do PR–SCTP sobre UDP no transporte
de dados em tempo real é que o PR–SCTP aproveita a sobra
de largura de banda para fazer retransmissões, o que aumenta
a resistência a perdas. O PR–SCTP também evita o
congestionamento de rede.
O encapsulamento RFC 2250 não adiciona muita
resistência a perdas ao MP3. Conforme mostra a Figura 11, o
fluxo UDP passou apenas em redes praticamente sem perdas e
banda confortável. O uso de SCTP ou PR–SCTP melhora
bastante a resistência do RFC 2250.
RTT da conexão e à banda passante. (A opção de um controle
de congestionamento mais amigável com fluxos multimídia
também seria interessante.)
O encapsulamento FEC utilizado nos testes da Figura 13
gera dados redundantes que permitem reconstruir os dados
perdidos. Isso aumenta a sobrecarga do protocolo, mas torna-o
perfeito para transporte não confiável como UDP.
Figura 13:
Correction)
Figura 11: Viabilidade de um fluxo de áudio RFC 2250
O encapsulamento RFC 3119 já acrescenta razoável
resistência a perdas de pacotes, conforme mostra a linha UDP
da Figura 12. O uso adicional de SCTP ou PR–SCTP torna o
fluxo multimídia resistente a perdas de até 5%.
Figura 12: Viabilidade de um fluxo de áudio RFC 3119
O PR–SCTP deveria ser muito mais resistente a perdas que
SCTP padrão, mas não foi o que aconteceu. O prazo de
validade fixo (200ms) mostrou não ser adequado. Um
protocolo multimídia idealmente adaptado a PR–SCTP
escolheria a validade dinamicamente, proporcionalmente ao
Viabilidade de um fluxo de áudio FEC (Forward Error
O SCTP padrão não apresentou bom resultado com FEC,
pois o SCTP tenta garantir a entrega de todas as mensagens, o
que implica numa banda mínima de 260kbps (que acomoda a
sobrecarga gerada pelo FEC de um MP3 de 192kbps). Na
verdade, esse teste foi executado apenas por completeza, pois
não traz proveito usar FEC sobre um transporte confirmado.
Já o PR–SCTP apresentou um resultado melhor que UDP
em quase toda a grade FEC, pois sabe aproveitar a sobra de
largura de banda para aumentar a resistência a perdas, atuando
sinergicamente com FEC.
IV. OUTROS TESTES DE DESEMPENHO SCTP
Diversos outros trabalhos comparam o desempenho do
SCTP frente a TCP. Desses, dois são particularmente
interessantes.
O artigo [15] testa HTTP sobre SCTP, com arquitetura e
software diferentes do presente trabalho, e chega a conclusões
análogas – que múltiplos fluxos SCTP aumentam o
desempenho de HTTP –, embora a métrica não tenha sido a
vazão, e sim a latência i.e. o tempo total que um usuário teria
esperado em frente ao navegador Web para a página ser
completamente carregada.
O artigo [16] explora a transferência de dados utilizando
um grande número de fluxos paralelos através de uma rede
com perdas, e atingiu desempenho bem melhor que TCP, o
que a priori contradiz os resultados deste artigo.
Porém, como o SCTP garante a ordem de entrega de
mensagens apenas dentro de cada fluxo, a perda de pacote de
um fluxo não atrasa a entrega de outro fluxo. Assim, o
impacto da perda de um pacote é minimizado. O mesmo efeito
pode ser conseguido marcando-se todas as mensagens como
urgentes.
Um protocolo de aplicação tem de ser especialmente
175
176
IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 3, JUNE 2007
adaptado para funcionar sobre um transporte com essas
características e.g. um protocolo como FTP presume que o
transporte garanta a ordem e teria de sofrer adaptação
elaborada para funcionar sobre um canal desordenado.
Já nos testes de desempenho bruto deste artigo, as
mensagens foram sempre entregues em ordem estrita através
de um único fluxo.
V.
CONCLUSÕES E TRABALHOS FUTUROS
Os testes mostram que o Linux Kernel SCTP tem
desempenho aceitável na transmissão bruta de dados, embora
consistentemente menor que TCP no mesmo sistema
operacional.
O pior resultado do teste deveu-se às configurações default
do SCTP que regulam a retransmissão de pacotes: RTO
mínimo e RTO inicial, em particular o primeiro.
A alteração mais importante, e mais fácil, a ser sugerida
para o protocolo SCTP é o ajuste das configurações RTO para
um patamar mais baixo. A diminuição do RTO mínimo eleva
prontamente o desempenho do SCTP para níveis semelhantes
ao do TCP.
O RTO mínimo do TCP no Linux é de 200ms. Desde que o
RTO mínimo do SCTP não seja posicionado abaixo desse
patamar, a lealdade entre SCTP e TCP é mantida (na verdade,
ela é melhorada; a configuração default é desleal e vantajosa
ao TCP).
Enquanto essa mudança não é feita no SCTP padrão, os
usuários do LK–SCTP podem ajustar o RTO mínimo por meio
da interface /proc/sys/net/sctp.
Outras razões para o menor desempenho do SCTP são a
sua maior sobrecarga inerente e a pouca idade da
implementação LK–SCTP, que ainda pode ser muito
otimizada.
Nos testes com aplicações reais, em que os novos recursos
do SCTP puderam ser aproveitados, SCTP conseguiu
apresentar desempenho melhor que TCP e UDP. Mesmo
levando em conta os problemas da implementação, o suporte a
SCTP traria vantagens de desempenho a muitas aplicações.
A adaptação de HTTP para SCTP ainda não consta de
nenhuma RFC. O rascunho de adaptação proposto em [8]
poderia ser refinado e formalmente proposto ao IETF.
A extensão PR–SCTP permite atribuir prazo de validade às
mensagens. Em sistemas de multimídia em tempo real, a
correta escolha dessas validades terminais influi
decisivamente na confiabilidade de entrega das mensagens e,
portanto, na qualidade da reprodução da mídia. Um trabalho
futuro poderia determinar uma fórmula ou algoritmo que
calcule o prazo de validade ideal, de modo que o PR–SCTP
forneça resistência a perdas ainda maior que a verificada nos
testes RTP deste artigo.
VI. REFERÊNCIAS
[1]
R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor,
I. Rytina, M. Kalla, L. Zhang, and V. Paxson, “Stream Control
Transmission Protocol http://www.ietf.org/rfc/rfc2960.txt,” RFC 2960
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
(Proposed Standard), Oct. 2000, updated by RFC 3309. [Online].
Available: http://www.ietf.org/rfc/rfc2960.txt
R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, and P. Conrad, “Stream
Control Transmission Protocol (SCTP) Partial Reliability Extension
http://www.ietf.org/rfc/rfc3758.txt,” RFC 3758 (Proposed Standard),
May 2004. [Online]. Available: http://www.ietf.org/rfc/rfc3758.txt
L. Coene, “Stream Control Transmission Protocol Applicability
Statement
http://www.ietf.org/rfc/rfc3257.txt,”
RFC
3257
(Informational),
Apr.
2002.
[Online].
Available:
http://www.ietf.org/rfc/rfc3257.txt
L. Ong and J. Yoakum, “An Introduction to the Stream Control
Transmission Protocol (SCTP) http://www.ietf.org/rfc/rfc3286.txt,” RFC
3286
(Informational),
May
2002.
[Online].
Available:
http://www.ietf.org/rfc/rfc3286.txt
Sítio do projeto LK–SCTP. http://lksctp.sourceforge.net/ (acessado em
28/Jul/2006).
Sítio do projeto IPTables. http://www.netfilter.org/ (acessado em
28/Jul/2006).
Sítio do projeto Netem. http://developer.osdl.org/shemminger/netem/
(acessado em 28/Jul/2006).
E. Pfützenreuter, “Aplicabilidade e desempenho do protocolo SCTP
(Stream Control Transmission Protocol). Dissertação de mestrado.
http://www.epx.com.br/mestrado (acessado em 01/nov/2005),” 2004.
Sítio do servidor Web thttpd. http://www.acme.com/software/thttpd/
(acessado em 28/Jul/2006).
Sítio
do
client
Web
httperf.
http://www.hpl.hp.com/research/linux/httperf/
(acessado
em
28/Jul/2006).
Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A
Transport
Protocol
for
Real-Time
Applications
http://www.ietf.org/rfc/rfc3550.txt,” RFC 3550 (Standard), July 2003.
[Online]. Available: http://www.ietf.org/rfc/rfc3550.txt
Sítio do programa poc. http://www.bl0rg.net/software/poc/ (acessado em
28/Jul/2006).
. Hoffman, G. Fernando, V. Goyal, and M. Civanlar, “RTP Payload
Format for MPEG1/MPEG2 Video http://www.ietf.org/rfc/rfc2250.txt,”
RFC 2250 (Proposed Standard), Jan. 1998. [Online]. Available:
http://www.ietf.org/rfc/rfc2250.txt
. Finlayson, “A More Loss-Tolerant RTP Payload Format for MP3
Audio http://www.ietf.org/rfc/rfc3119.txt,” RFC 3119 (Proposed
Standard),
June
2001.
[Online].
Available:
http://www.ietf.org/rfc/rfc3119.txt
R. Rajamani, S. Kumar, and N. Gupta, “SCTP versus TCP: Comparing
the performance of transport protocolos for Web traffic.
http://www.cs.wisc.edu/ sumit/extlinks/sctp.pdf
(acessado
em
26/jul/2006),” 2002.
S. Kang and M. Fields, “Experimental Study of the SCTP compared to
TCP http://ee.tamu.edu/ swkang/reports/elen602.pdf (acessado em
26/jul/2006),” 2003.
VII.
BIOGRAFIAS
Elvis Pfützenreuter é pesquisador no time de Plataforma do Instituto Nokia
de Tecnologia, Recife, Brasil. Mestre em Ciência da Computação pela
Universidade Federal de Santa Catarina. Suas áreas de interesse incluem
Redes de Computadores e Dispositivos Móveis.
Luis Fernando Friedrich é Professor Associado no Departamento de
Informática e Estatística da Universidade Federal de Santa Catarina, Brasil.
Pós-Doutorado na Universidade da Virgínia - EUA, Doutor em Engenharia
pela Universidade Federal de Santa Catarina - Brasil e Mestre em Ciência da
Computação pela Universidade Federal do Rio Grande do Sul. Suas áreas de
interesse de pesquisa incluem Sistemas Operacionais, Computação de TempoReal e Computação Paralela e Distribuída. Membro da Sociedade Brasileira de
Computação (SBC).