SMU29009: QoS e a Camada de Transporte

Uma aplicação multimidia

A concepção de uma aplicação multimidia:

• Serviço a ser oferecido
• Requisitos funcionais
• Requisitos não-funcionais

Ex:

• compartilhamento de video um-para-muitos (P2P)

Camada de transporte

Uma aplicação multimidia distribuída se comunica usando serviços da camada de transporte. Nessa camada há protocolos que implementam um serviço de comunicação fim-a-fim entre processos e através de uma rede não-confiável. As características dos protocolos de transporte influenciam o desempenho da aplicação multimidia, e por isso faz-se necessária uma revisão sobre os principais protocolos.

TCP

• Livro online: análise dos mecanismos do TCP

Negociação em três vias

• Three-way handshake

O estabelecimento de conexão TCP envolve o intercâmbio de três mensagens entre o iniciador (cliente) e o atendente da conexão (servidor).

Intercâmbio de mensagens para estabelecimento de conexão

Para o desempenho de uma aplicação, a principal consequência é a percepção de uma latência para iniciar a comunicação de fato. Para aplicações que transmitem frequentemente pequenas quantidades de dados, o estabelecimento de nova conexão para cada transmissão reduz a taxa efetiva de dados obtida (além da latência). Uma proposta para atenuar o problema se chama TCP Fast Open, aplicável em situações em que ocorrem múltiplas conexões sucessivas entre um mesmo par cliente-servidor. Essa melhoria possibilita que, a partir da segunda conexão, o lado servidor comece a transmitir dados imediatamente após a recepção da mensagem SYN.

Controle e prevenção de congestionamento

• Congestion Avoidance and Control

O controle de congestionamento é um importante serviço do TCP, o qual evita sobrecarga de tráfego em uma rede e seu consequente colapso devido a congestionamento. Fazem parte dele o controle de fluxo, a partida lenta, e a prevenção de congestionamento.

As consequências para o desempenho de uma aplicação são:

• Baixa taxa efetiva de dados para pequenas transferências de dados (e sensível ao atraso fim-a-fim)
• Variações abruptas na taxa de dados caso qualquer erro ocorra (necessidade de retransmissão)

Produto da largura de banda pelo atraso

• Bandwidth-Delay Product

O produto da largura de banda pelo atraso corresponde à quantidade de dados em trânsito e ainda não confirmados. Ele se define pelo produto da capacidade dos links pelo atraso fim-a-fim. Esse produto tem implicação importante nos tamanhos das janelas de recepção tanto do cliente quanto do servidor. A janela de recepção deve ser ajustada em função do RTT e da taxa de dados estimada. Se as janelas de recepção forem inferiores a esse produto, um transmissor deve pausar a transmissão para esperar confirmações (devido ao controle de fluxo), quando poderia transmitir mais dados. Isso tem impacto negativo no desempenho de uma aplicação.

Apesar de o tamanho da janela de receção se ajustar automaticamente com as condições da comunicação, há que cuidar para que seu limite superior não se torne um gargalo. Para uma aplicação que precise de maior desempenho, deve-se conferir se a opção de multiplicação da janela (Window Scaling Option) está ativada no sistema operacional.

Head-of-line blocking

• Head-of-Line Blocking

O bloqueio da frente da fila no TCP se deve ao seu mecanismo de garantia de entrega ordenada. Se uma mensagem se perde, o transmissor a retransmite, porém todas as mensagens subsequentes já recebidas no lado servidor ficam bloqueadas à espera da recepção da mensagem perdida. A aplicação que espera receber esses dados fica bloqueada até que a sequência bufferizada se complete, e possa ter acesso aos dados. Como consequência, isso causa uma variação imprevisível nos intervalos entre dados recebidos, chamado de jitter.

Ainda que uma aplicação não precise de entrega ordenada, ela está sujeita a essa penalidade. Por exemplo, uma aplicação que transmite mensagens individuais não precisa necessariamente que elas sejam entregues em ordem. Outro exemplo é uma aplicação em que novas mensagens substituem mensagens anteriores completamente (ex: mensagens de atualização de status de sensores): nesse caso, a entrega confiável se torna desnecessária. Em ambos casos, o protocolo TCP pode causar uma redução de desempenho, uma vez que não é possível desativar esses serviços. Para uma aplicação em que essas questões sejam críticas, pode ser mais adequado outro protocolo de transporte (ex: UDP ou DCCP).

Otimização para uso do TCP

• Optimizing for TCP
• Internet Draft: TCP Tuning for HTTP

UDP

• Livro online: análise dos mecanismos do UDP

O protocolo UDP nada mais faz do que implementar um serviço orientado a datagramas e com multiplexação baseado em ports sobre o protocolo IP. Assim, pode-se listar o que o UDP NÃO faz (comparando-o com TCP):

• Sem garantia de entrega de mensagem
• Sem garantia de entrega ordenada
• Sem conexão
• Sem controle de congestionamento

UDP e NAT

Na Internet em que ainda predomina o uso de IPv4, ou sua presença é ainda relevante, o uso de NAT continua necessário. Como UDP é um protocolo sem estado, os tradutores NAT precisam memorizar os endereços IP e ports de cada datagrama UDP sainte, para permitir a entrada de datagramas UDP em sentido contrário que tenham as mesmas características. Se a comunicação ficar ociosa mais tempo do que o tempo de memorização do tradutor NAT, datagramas UDP entrantes não conseguem mais atravessar o tradutor NAT. Uma aplicação precisa então transmitir com uma frequência suficiente para que o tradutor NAT mantenha em memória as informações sobre o fluxo UDP.

Outro problema relacionado com NAT se dá com comunicações UDP com aplicações que estão atrás de um tradutor NAT, as quais usam ports UDP randômicos e cujos endereços IP são variáveis (ex: telefones IP, Google Talk). Nesse caso, para que a comunicação ocorra é necessário primeiro que a aplicação identifique o endereço IP externo apresentado pelo tradutor NAT, para então oferecê-lo como endereço de contato para aplicações fora de sua rede. Para situações assim se criaram serviços como STUN, TURN e ICE.

STUN: Session Traversal Utilities for NAT

• RFC 5389

Ou: um quebra-galho para resolver os problemas de outro quebra-galho ...

O serviço STUN (Session Traversal Utilities for NAT) possibilita que uma aplicação baseada em UDP descubra seu endereço IP e port UDP visíveis para quem estiver do outro lado do gateway NAT. A figura abaixo ilustra como o STUN poderia ser usado para essa finalidade.

Cenário em que se poderia usar STUN

O STUN foi criado para ser usado imediatamente antes de iniciar uma transmissão UDP. Como mostrado na figura abaixo, um cliente envia a um servidor STUN uma mensagem de pedido de vinculação (binding request), que deve usar como port UDP de origem o mesmo port que se pretende usar para a stream de áudio. Esse servidor STUN deve estar fora da rede, de forma que o pedido de vinculação por ele recebido seja modificado pelo NAT. A resposta do servidor STUN (binding response) contém o endereço IP e número de port UDP que apareceram no pedido de vinculação. Com isso o cliente consegue descobrir como esses valores deverão aparecer após passarem pelo NAT. Assim, a mensagem SDP pode ser preenchida com os valores apropriados para a stream de áudio.

Exemplo de mensagens trocadas com STUN

Deve-se notar que o STUN não faz milagre ! Como apontado no início do texto, STUN é um quebra-galho criado para tentar resolver os problemas de outro quebra-galho (no caso, o NAT). Para que o STUN funcione, o NAT deve permitir que datagramas UDP vindos de outro endereço IP (o telefone VoIP na outra ponta da ligação) acessem o endereço IP e port UDP que foram alocados quando da consulta do cliente para o servidor STUN. Isso nem sempre é possível, pois depende do tipo de NAT: se for do tipo simétrico, o STUN sozinho não funcionará. E muitos NAT em equipamentos proprietários são do tipo simétrico (ao contrário do Linux, que implementa um NAT port restricted cone) ...

Existe uma implementação de um servidor STUN para Linux (disponível no Ubuntu via apt). Basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja do outro lado do NAT. No entanto, existem inúmeros servidores STUN públicos, conforme mostrado na listagem abaixo:

provserver.televolution.net
sip1.lakedestiny.cordiaip.com
stun1.voiceeclipse.net
stun01.sipphone.com
stun.callwithus.com
stun.counterpath.net
stun.endigovoip.com
stun.ekiga.net (alias for stun01.sipphone.com)
stun.ideasip.com (no XOR_MAPPED_ADDRESS support)
stun.internetcalls.com
stun.ipns.com
stun.noc.ams-ix.net
stun.phonepower.com
stun.phoneserve.com
stun.rnktel.com
stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stunserver.org see their usage policy
stun.sipgate.net
stun.sipgate.net:10000
stun.voip.aebc.com
stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stun.voxalot.com
stun.voxgratia.org (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stun.xten.com
numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS only with rfc3489bis magic number in transaction ID)
stun.ipshka.com inside UA-IX zone russsian explanation at http://www.ipshka.com/main/help/hlp_stun.php

TURN

o serviço TURN implementa um tipo de proxy UDP, para realizar o relay de datagramas UDP quando o uso de STUN não é suficiente.

Cenário de uso de TURN

Nesse caso, a aplicação se registra no servidor TURN, e então pode anunciar que seu endereço IP e port para recepção de datagramas UDP são aqueles do do servidor TURN. Ao receber um datagrama UDP destinado ao port registrado pela aplicação, o servidor TURN o encaminha para a aplicação de destino registrada.

ICE

O protocolo Interactive Connectivity Establishment (ICE) implementa mecanismos e procedimentos para facilitar a travessia de tradutores NAT. Ele facilita a seleção do método mais adequado de travessia: STUN se possível, caso contrário usando TURN.

DCCP

• Datagram Conection Control Protocol
• Usando DCCP

SCTP

• Stream Control Transmission Protocol
• Usando SCTP