View
49
Download
5
Category
Preview:
DESCRIPTION
Distribuição de Mídia Contínua Voz sobre IP. Jussara M. Almeida. Junho 200 5. 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 - PowerPoint PPT Presentation
Citation preview
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:
• 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
Recommended