Distribuição de Mídia Contínua
Voz 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:
•
–
A retransmissão é perdida:
•
–
Se perdas independentes a taxa p, probabilidade é
p  (1-p)  p = p2 – p3
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