O “Protocolo de Transmissão de Controle de Fluxo” (SCTP) é um protocolo de transporte confiável, combinando as vantagens do TCP/IP e UDP. SCTP tem muitas características desejáveis incluindo o “multihoming”, “multistreaming” e a confiabilidade dos dados parciais.

1. UNIVERSIDADE FEDERAL DO PARANÁ
PAULO CEZAR DIAS SILVEIRA
UM ESTUDO DA ROBUSTEZ DO PROTOCOLO SCTP PARA O TRANSPORTE
DE VÍDEO CODIFICADO ESCALONÁVEL
CURITIBA
2013

2. 2
1 INTRODUÇÃO
O “Protocolo de Transmissão de Controle de Fluxo” (SCTP) é um protocolo
de transporte confiável, combinandoas vantagens do TCP/IP e UDP. SCTP tem
muitas características desejáveis incluindo o “multihoming”, “multistreaming” e a
confiabilidade dos dados parciais. Estas características fazem com que o SCTP
tenha um desempenho muito mais efetivo em aplicações de redes multimídia. Elas
também funcionam melhor no ambiente sem fio no qual os tradicionais protocolos
são ineficazes e complicados. Antes da transmissão, uma aplicação utilizando SCTP
precisa estabelecer um vinculo entre o cliente e o servidor. O estabelecimento do
vinculo requer um conjunto de característicasque serãoutilizados para criar vários
fluxos. No entanto o SCTP não especificou um método ou sugeriu alguma ideia para
determinar estas características.
No campo das telecomunicações, o protocolo SCTP pode providenciar uma
solução para os problemasencontrados pelossistemas móveisTCP/IP e UDP. Ao
explorar as características ”multihoming” do protocolo SCTP para se conectaras
diversas redes sem fio separadas e ao mesmo tempo, possibilita que um nó móvel
escolha qual o caminho sem fio que atende as necessidades especificas de
aplicação que esta sendo executado pelousuário. No entanto, há uma desvantagem
para esse cenário – o atual sistema de transmissão implementado em SCTP é
centrado em falhas de natureza intrínseca ao sistema.Este estudo propõe uma
melhoria no sistema de transmissão com SCTP, utilizando dispositivos propostosnas
simulações o qual oferece o beneficio de realizar a transmissão com base em
atrasos medidos no trajeto, portanto não requer que uma falha no caminho de
transmissão ocorra. Em alguns casoso dispositivo pode realmente se antecipar a
falha de caminho e fazer a transmissão antes da ocorrência.
Para ter subsídios na elaboração, foi realizada uma pesquisa no site de
periódicos da “Capes”, buscando artigos científicos que abordassem o tema do
SCTP e com relevância na classificação. Nessa pesquisa foram filtrados artigos a
partir de 2010 que utilizassem aplicativos e simulações de testes dentro do contexto
atual da tecnologia, possibilitando agregar novas ferramentas com o objetivo de
atingir os resultadosplanejados dentro do projeto. Nessa pesquisa foi selecionado o
artigo “A Lightweight SCTP for PartiallyReliable Overlay VideoMulticast Service for
Mobile Terminals” dos autores “JinsukBaek ,Paul S. Fisher, MinhoJo e Hsiao-Hwa

3. 3
Chen”. O grau de relevância do artigo escolhido foi obtido através do Webqualis no
site da “Capes” e obteve-se a seguinte classificação:
ISSN Titulo Estrato Area Avaliação Classificação
1520-
9210
IEEE
TransactionsonMultimedia
A1 ENGENHARIAS
IV
Em
Atualização
2 RESUMO
A questão fundamental de interesse na abordagem de simulação de testes
com esse protocolo é a capacidade de prever a perda de pacotes e retransmitir os
pacotes perdidos tão brevemente quanto um terminal móvel “multi-homed” (host com
múltiplos endereços de IP e/ou conectado para múltiplos enlaces na mesma ou em
diferentes redes) complete o seu procedimento de mudança do caminho principal.A
simulação funciona com sobreposição ponto a ponto em instalações de vídeo
multicast na camada de aplicação. Para um terminal móvel “multi-homed”, uma
rajada de erros pode ocorrer quando um “handover” (comutação entre células) esta
em andamento no procedimento de mudança de caminho.O protocolo pode tolerar
perdas parciais na transmissão de vídeo desde que a perda seja limitada a um
numero relativamente pequeno de rajadas de erro. O objetivo da pesquisa é reduzir
significativamente o “overhead”e fornecer um mecanismo de comunicação
escalonável para aplicações “multicast”.
Muitos terminais moveis estão configurados em ambientes “multi-homed” por
simplesmente instalar duas ou mais interfaces de rede para suportar diferentes
protocolos.Os serviços de transferência de dados oferecidos pelos protocolos
tradicionais tais como TCP e UDP, são inadequados para estes ambientes devido ao
“multicasting” em IP não garantir a entrega confiável do datagrama, visto que a sua
transmissão exige que todos os roteadores implantados sejam atualizados com a
capacidade de “multicasting”.O protocolo de controle de transmissão do streaming
(SCTP) tem sido proposto como um protocolo na camada de transporte adequado
para o suporte de sobreposição para “multicast”, devido as suas características de
“multi-streaming” e “multi-homed”.
O recurso do “multi-homing” permite que um MR use mais de um endereço
para suportar mais de um recurso de comunicação que pode maximizar a utilização

4. 4
do ambiente “multi-homing” e aumentar a disponibilidade da rede.O protocolo SCTP
é um protocolo de transporte orientado para a conexão, providenciando confiável
entrega de mensagens ponto a ponto via seletivo ACK (SACK), controle de fluxo e
controle de congestionamento.O MR não mudara o seu caminho principal até que o
seu novo caminho seja ativado e seu novo endereço de IP atualizado para o MS.
Configuração da rede com sobreposição de serviço multicast
Durante este período o MR esta em seu estado inacessível, causando
perda de pacotes contínuos.Devido a sua abordagem de comutação do caminho
principal, um MR pode facilmente sofrer perdas de pacotes contínuos quando o MR
realiza um “handover”. O protocolo proposto exige que cada MR adaptativamente
decida se a retransmissão é necessária quando ele detecta a existência de múltiplos
caminhos, para proporcionar uma transmissão confiável parcialmente, baseada na

5. 5
velocidade esperada e na distância de movimento esperada do MR na área de
cobertura.Se perdas de pacotes contínuos são esperadas, o MR envia um retorno
para o MA depois de receber esta mensagem. O MA imediatamente retransmite os
pacotes para o MR sem esperar por outras mensagens para o mesmo pacote de
outros MRs. Se não são esperadas perdas de pacotes contínuos, os MRs também
enviam ACKs cumulativos em intervalos fixos e não frequentes.
O objetivo do estudo é propor um protocolo, chamado extensão do
“multicast” para abrir o primeiro caminho mais curto (MOSPF), no qual o “unicast”
recursivo foi utilizado para a escalabilidade na existência de protocolo de roteamento
“multicast”, para evitar a situação de encaminhamento dos pacotes para o roteador,
o qual evita custos de roteamento relativamente caros e do uso de larguras de
banda maiores devido ao uso do RTP comparado ao “multicasting” IP.O protocolo na
camada de transporte deve ser projetado para suportar perdas de pacotes
intermitentes apenas para atender suas características de perda tolerantes, mas
com características sensíveis a atrasos. Os pacotes, os quais são continuamente
perdidos, devem ser retransmitidos para o MR tão rapidamente quanto possível para
manter os requisitos doQoS. Perdas de pacotes podem acontecer de tempos em
tempos, porque cada MR adota um acesso de comutação do caminho principal.
Portanto, as perdas de pacotes tendem a ocorrer ao longo da rajada de erros,
durante o processo de “handover” do SCTP.As perdas de pacotes de erro ocorrem
durante rajadas curtas, separadas por períodos relativamente longos de transmissão
com sucesso. No entanto, se o comprimento de uma rajada de erro não é
significativamente longo, esses pacotes não precisam ser retransmitidos,
especialmente quando os pacotes são para a transmissão de dados de vídeo e tem
características de perda de tolerância.
Mudança de cenário do caminho principalMudança de cenário do caminho principal
com tempos decorridos já esperados com movimento esperado da distancia
O tamanho do buffer do MA para uma especifica sessão de “multicast” é
limitado. Portanto, o MA deve descartar periodicamente os pacotes a partir de seu

6. 6
buffer. Pacotes descartadoscom atraso resultam em um uso ineficiente do limite do
espaço do buffer no MA.O protocolo criado na simulação exige que o MR faça uma
previsão de quantos pacotes serão recebidos com sucesso na zona de cobertura e
quantos pacotes serão perdidos durante o período crítico acimado mencionado.Esta
previsão é executada tendo em conta a esperada velocidade do MR em movimento
quando ele está na área de sobreposição. Pode-se estimar a velocidade de
movimento dos MRs com base no tempo decorrido e movendo-se a distância que se
deslocam na rede atual. O protocolo exige que cada MR faça a previsão do número
de pacotes que seriam perdidos durante a execução do processo de comutação do
caminho principal para lidar com a rajada de erros. Uma vez que isto é conhecido, o
protocolo requisita a retransmissão daqueles pacotes antes dele experimentar uma
longa rajada de erros.No protocolo simulado, cada agente “multicast” (MA) é
requerido manter em seu buffer todos os pacotes que ele recebeu recentemente do
emissor de “multicast” (MS). Eles executam a recuperação de erros locais para todos
os seus receptores de “multicast”(MRs). Como os MAs tem tamanhos de buffer
limitados, precisamos de um mecanismo que permita que os MAs descartem
periodicamente os pacotes de seus buffers de forma segura. O SCTP fornece um
mecanismo desse tipo que emprega SAKS para cada pacote recebido com sucesso.
Analisando o desempenho do protocolo simulado(Baek, Fisher, Jo, & Chen,
2010), obteve-se como resultado que um pacote transmitido a partir do MA é perdido
devido a uma mudança do caminho principal, quando um MR executa um processo
de entrega. A notificação do estado do pacote entre os correspondentes dispositivos
não é instantânea. O atraso de retransmissão é importante para avaliar o
desempenho do protocolo criado. Por outro lado, o protocolo permite que um MA
retransmita imediatamente o pacote requisitado com uma mensagem, sem esperar
que a temporização de retransmissão expire. A vantagem do protocolo proposto é
que os MRs não são obrigados a transmitir mensagens de retorno desnecessárias
para o seu MA e o pedido de retransmissão previsto é mais importante para o
movimento rápido dos MRs, assim como a diferença aumenta linearmente em
função da velocidade. Isso permitirá que um MA possa lidar com um número muito
menor de mensagens de retorno enviadas por seusMRs. Ao comparar o protocolo
simulado para o legado do SCTP, verifica-se que este exige que todos os MRs
transmitam SAKs para cada pacote recebido com sucesso.

7. 7
Modelo esperado da rede
As características das transmissões de vídeo incluem a tolerância de perdas
de pacotes de curta duração, mas a intolerância para pacotes de longa duração.
Estes fatos implicam que todos os protocolos atuais são inadequados a nova
proposta de protocolo ponto a ponto para dispositivos móveis “multi-homed”, mas é
resistente às falhas de transmissão que resultaram do procedimento de comutação
do caminho principal.Perdas de pacotes são reduzidas antecipando a comutação do
caminho de rede, ou seja, para calcular a quantidade de pacotes que serão perdidas
em locais de rede previstos. Isso permite que os MRs recebam esses pacotes
imediatamente após a comutação do caminho das redes sem atraso.
REFERÊNCIAS

8. 8
Baek, J., Fisher, P. S., Jo, M., & Chen, H.-H. A Lightweight SCTP for Partially
Reliable Overlay Video Multicast Service for Mobile Terminals. , 12 IEEE
Transactions on Multimedia 754–766 (2010). Japan.
doi:10.1109/TMM.2010.2053523