Aplicações e Reserva de Recursos na Internet Sistemas Telemáticos LESI Grupo de Comunicações por Computador 2000

Aplicações e Reserva de Recursos na Internet

Sistemas TelemáticosLESI

Grupo de Comunicações por Computador2000

Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

Objectivos

Abordar os requisitos das novas aplicações no âmbito das redes de computadores.

Verificar a adequabilidade da filosofia best-effort a esses requisitos (alguns deles motivados pelas aplicações multimedia de tempo-real)

Técnicas usadas pelas aplicações T.R sobre cenários best-effort.

Novas soluções protocolares que garantam Qualidade de Serviço (QoS).


Classificação de Aplicações

Aplicações ElásticasAplicações de Tempo Real

Intolerantes Tolerantes


Classificação das Aplicações

Aplicações Elásticas ftp, e-mail, http, ....

Aplicações que não são extremamente sensíveis a factores como:

Atrasos, variação dos atrasos, variações de largura de banda, perdas, etc...

apesar desses mesmos factores afectarem o seu desempenho

Preocupação sob o ponto de vista de integridade do dados Protocolos de transporte tradicionais tais como: TCP,

UDP, ...


Aplicações de Tempo Real (audio e vídeo em tempo real, vídeo-conferência...)

Requisitos: garantia de isocronismo dos dados gerados, sensibilidade a atrasos, sensibilidade a perda de pacotes, necessidades de sincronização, largura de banda etc...

Duas classes de aplicações de T.R:

Classif. das Aplicações (cont.)

Aplicações Rígidas/Intolerantes Aplicações Adaptativas/Tolerantes


Aplicações de T.R.

Aplicações Rígidas Requerem suprtes que garantam limites para os diversos

parâmetros que as condicionam (largura de banda, perdas, atrasos de pacotes...)

Aplicações Tolerantes/Adaptativas Assumem um determinado grau de inadequação do meio não se baseiam em limites fixos para os parâmetros de

funcionamento admitem um grau de tolerância às condições de operação observação vs adaptação


Aplicações Adaptativas vs Intolerantes

Aplicações de T.R. (cont.)

desempenho

“cu

sto

”

T.R estrito

T.R tolerantes

Suportes Protocolares• Adequação aos objectivos das

aplicações

• Protocolos usualmente utilizados

• TCP - fiabilidade à custa de mecanismos nem sempre apropriados...

• UDP - carece de alguns mecanismos indispensáveis às aplicações de T.R.

• Natureza multi-utilizador de muitas das aplicações multimédia com requisitos de T.R paradigma de comunicação multi-ponto (multicasting)

• Desenvolvimento de aplicações com requisitos de T.R. Soluções propriétarias. (aplicação + transporte - ex. aplicações Vchat, Vosaic, CuSeeme, etc...)


Suporte de Aplicações Multimédia e de Tempo Real

Tempo Real sobre redes best-effort RTP (Real Time Protocol)

Reserva de Recursos RSVP (Resource Reservation Protocol)

Serviços Diferenciados


Protocolos Streaming

• Adequados para aplicações geradoras de tráfego T.R. sobre cenários best-effort (IP)

• Operação sobre cenários sem garantia de alocação de recursos

Conceitos:

• Tolerância a perdas de pacotes

• Controlo de atrasos (jitter vs buffers de amortecimento)

• Adaptação dinâmica dos serviços (mediante mecanismos de sinalização do estado de operação dos canais de dados)


Protocolo Streamming (cont)


Protocolo Streamming (cont.)


Protocolo RTP

Protocolo RTP (Real Time Protocol) (RFC 1889)

• Implementado como base às aplicações de T.R (adaptativas)

• Fornece mecanismos de transporte fim-a-fim a dados gerados por aplic. T.R

• Apto a ser aplicado em cenários unicast ou multicast

• Canal de dados + canal de controlo (RTCP - Real Time Control Protocol)

• RTCP - mecanismos de notificação do estado de operação do canal de dados (perdas, atrasos, sincronização etc ...)


Protocolo RTP (cont.)

• Camada Protocolar com o RTP (best-effort)

• Fornecer um mecanismo de transmissão a dados T.R.

• Fornecer mecanismos para controlo dos dados por parte da aplicação



• Sessão RTP = canal dados + canal de controlo

• Emissão de vários media- cada um é transmitido em sessões independentes

• Endereço de sessão = endereço de rede (unicast ou multicast) + porta protocolar

• Canal RTCP = porta protocolar do canal RTP+1



• Canal RTP - dados das aplicações

• Canal RTCP - dados de controlo

• informação de alto nível

•estatísticas sobre o desempenho dos receptores: perdas de pacotes , atrasos, jitter, inf. sincronização, etc...

• Cenários multicast:


RTP sobre Multicasting

• Protocolos de encaminhamento (diferentes filosofias)

• Protocolos de gestão de grupos multicast (IGMP)

• Túneis IP (interoperacionalidade entre encaminhadores)

• Propagação de sessões multicast (parâmetro TTL)


Formato Pacote RTP


Multiplexagem das sessões RTP

Cada média transportado numa sessão independente

Estratégia de multiplexagem: endereço de transporte (IP+Porta) Transitam pacotes dum único tipo (payload type) Gerados por uma ou mais entidades(SSRC)

Se as entidades trocarem entre si outro tipo de dados abre-se numa nova sessão RTP, independente da primeira


Real Time Control ProtocolProtocolo de controlo associado ao RTPUsado para trocar mensagens de controlo

entre os participantes Identificação de fontes: nome e email dos

participantes Mensagens do estado da sessão

Geradas por todos os participantesRelatar valores de diversos parâmetros: perdas,

atrasos, estados de sincronização• 2 tipos: sender report (SR) e receiver report (RR)


Mecanismos de Controlo

Variação nos atrasos dos pacotes - Jitter

• Influência no desempenho das aplicações (isocronismo).

•Cálculo nas estações

receptoras: jitterx = jitter(x-1) + fact*(dst - jitter(x-

1)), dst =

Diffdest(x,x-1) + Difforg(x,x-1)

• Necessidade de buffers de amortecimento.


Exercício para o cálculo de jitter

Suponha uma fonte que gera pacotes com intervalos de 20 ms. Enviaram-se 70 pacotes: os 12 primeiros pacotes chegaram ao destino com uma diferença de 40ms os 14 seguintes com diferença de 60 e os restantes com a diferença de 20 ms. Calcule o jitter usando um factor de amortecimento de 1/8.


Solução do Exercício

Cálculo do Jitter

0

5

10

15

20

25

30

35

40

1 6 11 16 21 26 31 36 41 46 51 56 61 66

Pacotes Recebidos

Jitt

er (

ms)

Jitter Estimado


Buffers de Amortecimento

• Amortecer o efeito da variação dos atrasos (assegurar isocronismo)

• Reordenação de pacotes

• Análise de n amostras e cálculo de um valor de amortecimento a ser adoptado. D = u(1) - u(n) com u(k) - késsimo maior valor dos atrasos das amostras.

•Antes de começar a reproduzir espera-se um determinado tempo.

n n-1 n-2 n-3

t1 t2 t3D

EMISSORRECEPTOR n n-1 n-2 n-3

tf tf tf



Exercício

Considere o receptor de uma cadeia de vídeo que tem uma taxa média a longo prazo de 100 Mbps

(a) Qual é o intervalo médio entre pacotes se cada pacote tem o tamanho de 1KB? O intervalo entre pacotes deve ser medido do 1º bit de um pacote e o 1º bit do pacote seguinte.

(b) Suponha que o maior intervalo possível entre pacotes é de 500 ms. Qual deve ser o ponto de reprodução para assegurar que todos os pacotes (quadros) chegam a tempo?

(c) Qual o tamanho do buffer necessário para suportar este ponto de reprodução?


Solução

(a)100Mb de dados vai ser transferido durante um segundo. Precisa de 100Mb/1000*8b = 12500 pacots. Intervalo entre pacotes = 1/12500 = 80 us

(b) Comparado com 500ms, 80us(o tempo para transferir um pacote) é muito pequeno. O tempo de reprodução é 500ms.

(c) Buffer = 0,5 * 100Mbps = 6.1MB


O erro do João

O João decide que para a sua aplicação de vídeo recuperar das perdas na Internet o seu ponto de reprodução (playback point) deve ser igual ao RTT actual do originador. Ele visualiza na sua aplicação multimédia vídeos dos 4 cantos do mundo. Ele constata que para os maiores RTTs o seu vídeo comporta-se bem enquanto para os RTTs mais curtos perde vários quadros. Que erro está a fazer o João?


Sugestão ao João

O ponto de reprodução deve depender do jitter do atraso e não do atraso fim-a-fim (RTT) para assegurar uma reprodução sem problemas. O que está acontecer neste caso é que para RTTs curtos o jitter é maior que o RTT e isso provoca a perda dos pacotes atrasados; no caso dos RTTs maiores o jitter é menor que o RTT e perdem-se muito menos pacotes.


Preservação Temporal Tentar reproduzir a

informação que obedeça ao limite temporal imposto

Preservação de Informação Tentar reproduzir toda a

informação recebida independentemente. De estar atrasada ou não

D D(1)

(2)

(3)

(4)

(5)

(6)

(7)

(9)

(8)

(1)

(2)

(3)

(6)

(8)

(9)

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(9)

(8)

Recepção dos pacotes Preservação

da Informação

Preservação Temporal

•Probabilidades diferentes de cortes nos media

Estratégias de Reprodução



Preservação de Informação

Quebra no pacote i se: u(i) > (u(0) + D) e u(i) > u(1), u(2)..u(i-1)

Cálculo da probabilidade de quebra baseado em funções de distribuição de probabilidades dos atrasos e função de distribuição de tempos de amortecimento.

Preservação Temporal

Quebra no pacote i se: u(i) > u(0) + D idem - maior número de quebras.... mas com outras

vantagens

Estratégias de Reprodução (cont.)



Perda de Pacotes

• Afectam desempenho das aplicações.

• Situações de saturação da infra-estrutura.

• Cada receptor mantém estatísticas das perdas verificadas informa periodicamente as entidades emissoras.

filtroperdas=fact * (filtroperdas)+ (1-fact)*percperdas com (0<fact<1)

• Percperdas presentes nos pacotes RTCP

• Definição de limites para o filtro de análise de perda de pacotes.


Perdas de Pacotes (cont.)

• Indicador para a aplicação diminuir o seu débito (alteração de codificações, diminuição do frame-rate, etc...)

• Receptor define limites inferiores/superiores para as percentagens admissíveis de perda de pacotes

• (> limite_superior) dimin. débito ; (< limite_inferior) aum. débito.


Adaptação às perdas

Adaptação Dinâmica

0

10

20

30

40

50

60

20 40 60 80 100 120 140 160 180 200

tempo(s)

Déb

ito

ger

ado

pel

a ap

licaç

ão (

kbyt

es/s

)

Débito gerado

Perdas/pacotes(%)

Estatistica/perdas(%)



Perda de Pacotes - Ambientes multicast (n participantes)

• Vários receptores diferentes situações de operação.• Decisão a tomar pelos emissores?

• Atender ao pior caso?

• Ponderação dos estados dos intervenientes (classificação das entidades + algoritmo de decisão).

• Emissão simultânea de um mesmo medium codificado de diferentes maneiras:

• Cada codificação numa sessão multicast independente

• Cada receptor escolhe a mais apropriada

• Vantagens/inconvenientes...



filtroperdas

%PERDAS

0%

100%

lim_inf

lim_sup%Perdas anunciada Sem perdas

CongestionadaNormal

Se ((Nentcong/Ntot) > %entcong)

Se (Nentnorm/Ntot) > %entcong)

Senão

Débito - Diminuição, aumento,continuação

Técnica de ponderação de estados dos receptores

• Cada receptor é classificado e depois é tomada uma decisão de débito de informação.



• Cenário multicast com 3 entidades (A,B,C). C relata as perdas; a partir de um dado instante as perdas de C ultrapassam os limites admissíveis pelos emissores A e B; A e B diminuem os débitos; as %ens perdas em C diminuem.

A

B

C

RTP sobre multicast

Perdas de pacotes observadas por C

0

5

10

15

20

25

0 3 6 9 12 15 18

tempo(seg)

nº

acu

mu

lad

o d

e p

aco

tes

per

did

os

Entidade A

d(t)


0

5

10

15

20

0 3 6 9 12 15 18

tempo(seg)

nº

acu

mu

lad

o d

e p

aco

tes

per

did

os

Entidade B

d(t)



Módulo Sincronização

• Emissores enviam + do que 1 medium

• Transmissão em sessões distintas (assumido pelo RTP)

• Afectados por condições variáveis (perdas, atrasos ....)

• Processamento local das estações

• Necessidade de sincronização periódica dos dados pelas entidades receptoras.

• fsincroniza(Ses1,Ses2) : nºpacotes de desfazamento entre as sessões como medida dessa dessincronização (+Ses1 atrasada, -Ses2 atrasada)


Sincronização (cont.)

Canal A

Canal BRECEPTOR

eliminação

buffering

EMISSOR

pontos de sincronização

•Como é realizada a sincronização ?

•Através da informação presente nos pacotes RTCP de cada uma das sessões:

“no instante x do emissor o último pacote do canal A estava etiquetado com t1, no instante y do emissor o último pacote do canal B estava etiquetado com t2”


Sincronização (cont.)• Mesmo cenário multicast (entidades A, B C)

• Problemas de sincronização aumentam com a escala da infra-estrutura utilizada

0 0,6 1,2 1,8 2,4 3Cenário1 0 0 0 0 0 0

Perdas de Pacotes

0

5

10

15

20

25

30

35

40

nº

pac

ote

s p

erd

ido

s

Cenário 1

Cenário 2

Sincronização

-2

-1

0

1

2

3

4

0 2 4 6 8 10 12tempo(seg)

nº

pac

ote

s

Cenário2

Sincronização

-2

-1

0

1

2

3

4

0 2 4 6 8 10 12

tempo(seg)

nº

pac

ote

s

Cenário1


0

5

10

15

20

25

0 3 6 9 12 15 18

tempo(seg)

nº

acu

mu

lad

o d

e p

aco

tes

per

did

os Entidade A

Cenário 1 0 0 0 1 0 0Cenário 2 0 0 0 0 0 0

Cenário 1 9 7 10 10 10 11Cenário 2 11 11 10 11 18 11 Perdas de Pacotes

0

5

10

15

20

25

30

35

40

nº

pac

ote

s p

erd

ido

s

Cenário 1

Cenário 2

Sincronização

-2

-1

0

1

2

3

4

0 2 4 6 8 10 12tempo(seg)

nº

pac

ote

s

Cenário2

Sincronização

-2

-1

0

1

2

3

4

0 2 4 6 8 10 12

tempo(seg)

nº

pac

ote

s

Cenário1

Sincronização

-12-10-8-6-4-202468

0 2 4 6 8 10 12

tempo(seg)

nº

pac

ote

s

Cenário3

1,9 1,7 3,5 3,4 5 4,2 45,1 4 6 3 6 5 4

Variação no Atraso

0

5

10

15

20

25

30

Jitt

er (

m\s

)

Cenário 1

Cenário 2

Sincronização

-2

-1

0

1

2

3

4

0 2 4 6 8 10 12tempo(seg)

nº

pac

ote

s

Cenário2

Sincronização

-12-10-8-6-4-202468

0 2 4 6 8 10 12

tempo(seg)

nº

pac

ote

s

Cenário3


RTP (cont.)

Encapsulamento de diferentes media sobre o RTP (grupo AVT do IETF)

Compressão dos cabeçalhos RTPdiminuir a sobrecarga por eles gerados.

Questões de segurançaencriptação de conteúdos.geração aleatória de estampilhas temporais e

identificadores Mecanismos de gestão e notificação de sessões

Protocolo SDP - Session Description Protocol Mixers - Entidades modificadoras dos conteúdos dos

pacotes RTP.

Documents

Aplicações e Reserva de Recursos na Internet Sistemas Telemáticos LESI Grupo de Comunicações por Computador 2000