Distribuição de Mídia Contínua Voz sobre IP

Distribuição de Mídia ContínuaVoz sobre IP Jussara M. Almeida Junho 2005

Voz sobre IP • Comunicação interativa • Altos requisitos de latência e perdas de pacotes • Atrasos de 100-150 ms ou acima disto são perceptíveis ao ouvido humano • Seres humanos têm baixa tolerância à degradação de áudio • Objetivo primário: minimizar latência • Objetivo secundário: minimizar perdas de pacotes

Voz sobre IP • Métodos atuais: • UDP • Retransmissão de pacotes perdidos podem não chegar a tempo no destino • Protocolos confiáveis como TCP travam em falhas de retransmissão ou timeouts • FEC e/ou packet loss concealment • Recuperação limitada para perdas em rajadas ou perdas súbitas

Voz sobre IP na Internet Atual • Perdas em rajadas são comuns • Probabilidade condicional de um pacote ser perdido dado que o ultimo pacote foi perdido é de 0.72 (muito alto) • Modelo de perdas: 2 estados • Falhas de links podem durar muito tempo : 5% das falhas duram mais que 2 horas • Estas características limitam eficácia de VoIP

Voz sobre IP: Avaliação Inicial • Avaliação no ambiente Emulab • Transferência de 5 minutos de voz • Rede com atrasos de 50 ms e banda de 10Mbps: link transcontinental • Taxas de perdas variáveis • Métrica: • PESQ: Perceptual Evaluation of Speech Quality • PESQ = 4 : qualidade de telefone

Voz sobre IP: Avaliação Inicial • Mesmo perda de 0.5%, PESQ < 4 para prob. rajada de 0.75 • Internet atual: perda de 0.42% com prob. rajada de 0.72 • Logo: precisa de novas soluções

Proposta • Arquitetura overlay que melhora o desempenho de aplicações VoIP quando serviço da Internet sofre • Taxa de entrega de pacotes alta mesmo frente a altas perdas com baixo overhead (baixa latência) • Comunicação end-to-end pelo overlay: divisão do caminho em vários segmentos de overlay • É possível recuperar pacotes com pouco atraso: recuperação local tem baixo overhead pois links do overlay tem baixo RTT se comparado à latência do caminho total • Algoritmo de roteamento pode se adaptar evitando links do overlay congestionados (alta perda ou indisponíveis)

Proposta • Contribuições: • Um protocolo de recuperação de pacotes em tempo real que entrega pacotes recebidos como UDP mas que realiza recuperação de pacotes de forma local • Tenta-se a recuperação somente uma vez e somente se for provável que o pacote chegue ao destino em tempo • Protocolo de roteamento no overlay adaptativo específico para VoIP que seleciona o caminho com base em uma métrica que combina a latência e a perda observada nos links

Arquitetura Overlay • Spines: implementa protocolos específico para a aplicação • Manutenção da rede: pings periódicos • Pacotes com número de sequência: deteção de perdas • Atribui um custo a cada link do overlay com base na perda e latência observadas no link • Custo de links disseminados pela rede de forma incremental • Melhorar VoIP: novos protocolos para • Recuperação localizada de pacotes • Roteamento adaptativo

Protocolo de Retransmissão em Tempo Real • Recupera pacotes somente se há uma possibilidade dele chegar a tempo no destino • Cada nó no overlay mantém um buffer circular de pacotes para cada link de saída • Pacotes são mantidos no buffer por um período igual ao atraso máximo suportado pelo codificador de voz • Nós intermediários enviam pacotes à medida que eles chegam, mesmo fora de ordem • Ao detetar uma perda, um nó envia um NACK requisitando cópia ao vizinho superior • Pedido de retransmissão enviado somente uma vez • NACKs limitam tráfego de controle quando não há perda

Protocolo de Retransmissão em Tempo Real • Quando um nó recebe um pedido de retransmissão, ele: • Checa se ele tem o pacote no seu buffer circular • Se tem re-envia, se não tem, não faz nada • Número máximo de retransmissões regulado em função do número de pacotes enviados: limita retransmissões em links com muitas perdas • Se um nó recebe o mesmo pacote duas vezes, somente a primeira cópia será transmitida para frente

Protocolo de Retransmissão em Tempo Real • Protocolo não envia ACKs positivos: • Não acarreta tráfego adicional se não há perda (exceto pelos pings) • Protocolo não trava para recuperar pacotes • Não tem timeouts • Desvantagem: não recupera todos pacotes • Pedido de retransmissão é perdido: • Se perdas independentes a taxa p, probabilidade é p  (1-p)  p = p2 – p3 • A retransmissão é perdida: • Probabilidade: p  (1-p)  (1 – p)  p = p2 – 2p3 + p4 • Probabilidade de perda total ~ 2p2 – 3p3

Protocolo de Retransmissão em Tempo Real • Distribuição da latência dos pacotes em um link com atraso T e taxa de perda p: • (1 – p) dos pacotes terão latência T • (p - 2p2 + 3p3) dos pacotes terão latência 3T +  •  = tempo para nó detetar perda •  depende dos tempos entre chegadas de pacotes e do número máximo de pacotes fora de ordem que o protocolo suporta • Um pacote fora de ordem dispara pedido de retransmissão: latência é crucial • Distribuição de latência em caminho com múltiplos links é composta das latências em cada segmento

Avaliação • Implementação em Spines e avaliação no Emulab • Cada experimento : 10 fluxos de VoIP • Perda de pacotes após protocolo: • link de 10 ms: vários níveis de perdas e rajadas Nível de rajada com pouco impacto Aplicação do protocolo em link com 5% de perda reduz perda por um fator de 10 (0.5%)

Avaliação • Perda de pacotes após protocolo: • Dois links concatenados de 10 ms cada Nível de rajada com pouco impacto Aplicação do protocolo em link com 5% de perda reduz perda por um fator de 10 (0.5%)

Avaliação • Distribuição da latência • Um link de 10 ms e 5% de perdas • 95% dos pacotes chegam em 10 ms • 4.5% chegam em 30 ms mais tempo entre chegadas de pacotes • Varia com rajadas • 0.5% dos pacotes são perdidos

Avaliação • Distribuição da latência • Concatenação de 2 links: cada um 10 ms e 5% de perdas • Somente 1% dos pacotes são efetivamente perdidos • 0.25% dos pacotes chegam com latência de 66ms: perdas nos dois links (0.05 X 0.05)

Avaliação • Impacto do protocolo na qualidade da voz • Rede com 5 segmentos de 10 ms cada • 10 fluxos VoIP de A pra F • Perdas entre C e D • Limite de atraso de 100 ms

Avaliação • Com novo protocolo, independente de rajada ou não, o codec em questão pode supeortar até 3.5% de perdas para garantir qualidade de telefone

Protocolo de Roteamento em Tempo Real • Objetivo: max # pacotes que chegam no destino dentro do limite imposto pelo codec (ex: 100ms) • Duas métricas por link: latência e taxa de perda • Computar a distribuição de latência para todos os caminhos possíveis e escollher o melhor é ótimo mas muito caro • Solução: • aproxima custo de cada link por uma métrica dependente da latência e taxa de perdas • Usa algoritmo do caminho mais curto com esta métrica

Protocolo de Roteamento em Tempo Real • Métrica: latência esperada • Latência esperada em um link: Texp = (1 – p)T + (p - 2p2 + 3p3 )(3T+ ) + (2p2 + 3p3)Tmax • Latência esperada em um caminho: soma das latências nos links

Avaliação • Topologias aleatórias criadas com o gerador Brite • Para cada topologia, avalia o roteamento entre o par de nós que estão mais distantes • % de pacotes que chegam ao destino a tempo (100 ms) • Métricas para roteamento • Latência esperada: Cost = Texp • Distância em hops : Cost = 1 • Latência do Link: Cost = T • Taxa de perdas: Cost = - log(1 – p) • Otimizador guloso: Dijkstra modificado onde a cada iteração, escolhe o próximo nó com taxa de entrega máxima • Ótimo

Avaliação • Topologias com diâmetro pequeno: roteamento baseado na taxa de perdas é melhor • Topologias com diâmetro grande: latência é + importante • Latência esperada: bom compromisso

Distribuição de Mídia Contínua Voz sobre IP