6 Redes Multimedia

Multimédia, Qualidade de Serviço (QoS): O que são?
Aplicações Multimédia:
áudio e vídeo pela rede
(meios contínuos)
QoS
a rede oferece às
aplicações o nível de
desempenho necessário
para funcionarem.
Redes Multimédia 6-1
Capítulo 6: Objectivos
Princípios
❒ Classificar aplicações multimédia
❒ Identificar os serviços da rede que as aplicações
necessitam
❒ Obtendo o melhor de um serviço melhor esforço
❒ Mecanismos para oferecer QoS
Protocolo e Arquitecturas
❒ Protocolos específicos para melhor esforço
❒ Arquitecturas para QoS

Capítulo 6: Sumário
❒ 6.1 Aplicações de Rede ❒ 6.5 Para além do Melhor
Multimédia Esforço
❒ 6.2 Fluxos de áudio e ❒ 6.6 Mecanismos de
vídeo armazenados Serviço e Policiamento
❍ RTSP ❒ 6.7 Serviços Integrados
❒ 6.3 Multimédia de Tempo ❒ 6.8 RSVP
Real: Estudo do caso do

❒ 6.9 Serviços
Internet Phone
Diferenciados
❒ 6.4 Protocolos para
Aplicações Interactivas
de Tempo Real
❍ RTP, RTCP
❍ SIP
Aplicações de Rede Multimédia
Características
Classes de aplicações MM:
Fundamentais:
1) Fluxos de áudio e vídeo
Tipicamente sensíveis ao
gravados
❒
atraso
2) Fluxos de áudio e vídeo ao
❍ atraso extremo a extremo
vivo
❍ variação do atraso (jitter)
3) Áudio e vídeo interactivos
❒ Mas tolerante a perdas:
em tempo real
perdas raras causam
pequenos ruídos
Jitter é a variação dos ❒ Antítese da transmissão

atrasos dos pacotes de dados, que não é
dentro do mesmo fluxo tolerante a perdas mas
de pacotes tolera atrasos.

Fluxos Multimédia Armazenados
Transmissão de Fluxos
(Streaming):
❒ dados armazenados na fonte
❒ transmitidos para o cliente
❒ fluxos: o cliente começa a
apresentação antes de todos
os dados chegarem
❒ restrições temporais para os dados ainda por
transmitir: a tempo para serem apresentados
Fluxos Multimédia Armazenados:
O que são?
Dados cumulativos
2. vídeo
enviado
1. vídeo 3. vídeo recebido,
gravado
atraso da apresentado no cliente
rede
tempo
fluxo: neste instante, o cliente
apresenta a parte inicial do vídeo,
enquanto o servidor ainda envia a parte
final do vídeo

Fluxos Multimédia Armazenados: Interactividade
❒ funcionalidade tipo gravador de vídeo:
o cliente pode fazer pausa, recuar,
avançar, saltar para outra parte
❍ atraso inicial de 10 seg OK
❍ 1-2 seg até o comando actuar OK
❍ uso frequente de RTSP (mais em breve)
❒ restrições temporais para os dados ainda por
transmitir: a tempo para serem apresentados
Fluxos Multimédia ao Vivo
Exemplos:
❒ Espectáculo de rádio via Internet
❒ Transmissão directa de evento desportivo
Transmissão de Fluxos
❒ buffer de apresentação
❒ a apresentação pode atrasar-se dezenas de
segundos depois da transmissão
❒ ainda tem restrições temporais
Interactividade
❒ impossível avançar
❒ voltar atrás, pausa possíveis!

Multimédia em tempo real, interactiva
❒ aplicações: telefone IP,
videoconferência, mundos
interactivos distribuídos
❒ requisitos de atraso:
❍ áudio: < 150 mseg bom, < 400 mseg OK
inclui atrasos da aplicação (enpacotamento) e da rede
atrasos mais elevados notados, prejudicam interactividade
❒ iniciação da sessão
❍ como o chamado anuncia o seu endereço IP, número
de porto, algoritmos de codificação?
Multimédia na Internet de Hoje
TCP/UDP/IP: serviço melhor esforço
❒ sem garantias no atraso, perdas
?
? ? ?
? ?
Mas disse-se que as aplicações multimédia
precisavam de QoS e de um certo nível ?

?
de desempenho para serem eficazes!
?
? ?
As aplicações multimédia na Internet de hoje
usam técnicas na camada de aplicação para
minimizar (o melhor possível) os efeitos dos
atrasos, perdas

Como deve a Internet evoluir para
melhor suportar multimédia?
Filosofia de Serviços Integrados: Filosofia de Serviços
Diferenciados:
❒ Mudanças importantes na
Internet para que as aplicações ❒ Poucas mudanças na infra-
possam reservar largura de estrutura da Internet, mas
banda extremo a extremo oferecer serviço de 1ª e 2ª
classe.
❒ Necessita de software novo,
complexo nos sistemas
terminais & routers
Laissez-faire
❒ nenhuma mudança importante
❒ mais largura de banda quando
necessário
❒ distribuição de conteúdos,
Qual a sua opinião?
multicast na camada de
aplicação
❍ camada de aplicação Redes Multimédia 6-11
Algumas palavras sobre compressão de áudio
❒ Sinal analógico amostrado ❒ Exemplo:
a um ritmo constante 8 000 amostras/seg,
❍ telefone: 8 000 256 valores de quantização
amostras/seg --> 64 000 bps
CD de música: 44 100
Receptor converte de
❍
❒
amostras/seg
volta para um sinal
❒ Cada amostra quantizada,
analógico:
ie, arredondada
❍ alguma redução de qualidade
eg, 2 =256 possíveis valores
8
❍
Exemplos de ritmos
de quantização
❒ CD: 1.411 Mbps

❒ Cada valor quantizado
representado por bits ❒ MP3: 96, 128, 160 kbps
❍ 8 bits para 256 valores ❒ Telefone Internet:
5.3 - 13 kbps

Algumas palavras sobre compressão de vídeo
❒ O vídeo é uma sequência Exemplos:
de imagens apresentadas ❒ MPEG 1 (CD-ROM):

a um ritmo constante 1.5 Mbps
e.g. 24 imagens/seg
MPEG2 (DVD): 3-6 Mbps
❍
❒
❒ Uma imagem digital é
❒ MPEG4 (uso frequente na
uma matriz de pixels
Internet, < 1 Mbps)
❒ Cada pixel é
Investigação:
representado por bits
❒ Vídeo em camadas
❒ Redundância
(escalável)
❍ espacial
❍ adaptar camadas à largura
temporal
de banda disponível
❍

❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP

Fluxos Multimédia Armazenados
Técnicas de transmissão de
fluxos ao nível da camada
de aplicação para obter os Media Player
melhores resultados dos

remoção de jitter
serviços melhor esforço:
❒
❒ descompressão
❍ buffers no lado do
❒ ocultação de erros
cliente
❒ interface de utilizador
❍ uso de UDP versus TCP gráfica com controlo de
interactividade
❍ múltiplas codificações
multimédia
Multimédia na Internet: aproximação mais simples
❒ áudio ou vídeo armazenado em
ficheiro
❒ ficheiros transferidos como
cliente objectos HTTP
❍ inteiramente recebidos no
cliente
❍ depois apresentados
não há fluxos de áudio, vídeo:
❒ sem pipelining, longos atrasos até à apresentação!

Multimédia na Internet: aproximação com fluxos
❒ o browser faz GET de um metaficheiro
❒ o browser lança o Media Player, passando o metaficheiro
❒ o Media Player contacta o servidor
❒ o servidor envia o fluxo de áudio/vídeo para o Media Player
Recebendo um fluxo de um servidor de fluxos
cliente servidores
❒ Esta arquitectura permite um protocolo diferente do
HTTP entre o servidor e o media player
❒ Também pode utilizar UDP em vez de TCP.

Fluxos Multimédia: Buffers no Cliente
transmissão de
Dados cumulativos
vídeo de ritmo recepção do

apresentação
constante vídeo no cliente
do vídeo a ritmo
constante no cliente
atraso na
rede
vídeo em
buffer
variável
atraso de tempo
apresentação
❒ Os buffers no lado do cliente e atrasos na
apresentação compensam os atrasos da rede e
variação do atraso (jitter)
Fluxos Multimédia: Buffers no Cliente
buffer
do
ritmo de cliente
enchimento
ritmo de
variável,
consumo
x(t) para
constante
da
descompressão,
rede
apresentação
vídeo em
buffer
❒ Os buffers no lado do cliente e atrasos na
apresentação compensam os atrasos da rede e
variação do atraso (jitter)

Fluxos Multimédia: UDP ou TCP?
UDP
❒ o servidor envia ao ritmo apropriado para o cliente (esquece a
congestão da rede !)
❍ frequentemente, ritmo de envio = ritmo de codificação = ritmo
constante
❍ então, ritmo de enchimento = ritmo constante - perdas de pacotes
❒ atraso de apresentação curto (2-5 segundos) para compensar a
variação do atraso da rede (jitter)
❒ recuperação de erros: se o tempo permitir
TCP
❒ envia ao ritmo máximo possível por TCP
❒ ritmo de enchimento flutua devido ao mecanismo de controlo de
congestão de TCP
❒ maior atraso de apresentação: suavizar o ritmo de entrega TCP
❒ HTTP/TCP passa mais facilmente por firewalls

Fluxos Multimédia: ritmo(s) dos clientes
codificação a 1,5 Mbps
codificação a 28.8 Kbps
Q: como tratar diferentes ritmos de recepção
dos clientes?
❍ ligação telefónica a 28.8 Kbps
❍ Ethernet a 100Mbps
R: o servidor armazena, transmite múltiplas cópias
do vídeo, codificadas a diferentes ritmos

RTSP: Real-Time Streaming Protocol
Controlo pelo utilizador dos fluxos multimédia
HTTP O que não faz:
❒ Não é dirigido a conteúdos ❒ não define como o áudio/vídeo
multimédia é encapsulado para ser enviado
❒ Não tem comandos para como um fluxo pela rede
avanço rápido, etc. ❒ não restringe como os fluxos
RTSP: RFC 2326 múltimédia são transportados;
podem ser transportados por

❒ Protocolo cliente/servidor
UDP ou TCP
da camada de aplicação.
❒ não especifica como o Media
❒ Para o utilizador controlar:
Player armazena o áudio/vídeo
rebobinar, avanço rápido,
em buffers
pausa, continuar,
reposicionar, etc
RTSP: controlo fora de banda
O FTP utiliza um canal de As mensagens RTSP também
controlo fora de banda: são enviadas fora de banda:
❒ Um ficheiro é transferido ❒ As mensagens de controlo
por uma ligação TCP. RTSP usam números de
portos diferentes do fluxo

❒ A informação de controlo
multimédia: fora de banda.
(mudanças de directoria,
Porto 554
apagar ficheiros, mudar
❍
nomes de ficheiros, etc.) é ❒ O fluxo multimédia é
enviada por uma ligação considerado dentro de
TCP separada. banda.
❒ Os canais fora de banda e
dentro de banda utilizam
diferentes números de
portos.

Exemplo de RTSP
Cenário:
❒ metaficheiro enviado ao web browser
❒ browser lança Media Player
❒ o Media Player estabelece uma ligação RTSP de
controlo, uma ligação de dados para o servidor de
fluxos multimédia
Exemplo de Metaficheiro
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>

Funcionamento do RTSP
cliente servidor
Exemplo de Interacção RTSP
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0

Cseq: 1
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 OK
Cseq: 1
Session: 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231
Range: npt=0-
C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Range: npt=37
Cseq: 3
Session: 4231
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Cseq: 4
Session: 4231
S: RTSP/1.0 200 OK
Cseq: 4
Session: 4231

❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP
Aplicações interactivas de tempo real
Vamos agora analisar

❒ telefone PC a PC
em detalhe um
❍ os serviços de
mensagens instantâneas exemplo de telefone
oferecem isto via Internet PC a PC
❒ telefone PC a telefone
❍ Dialpad
❍ Net2phone
❒ videoconferência com
Webcams

Multimedia Interactiva: Internet Phone
Introdução ao Internet Phone através de exemplo
❒ áudio de uma pessoa a falar: alternadamente trechos de
voz, períodos de silêncio.
❍ 64 kbps durante um trecho de voz
❒ apenas são gerados pacotes durante trechos de voz
❍ blocos de 20 mseg a 8 Kbytes/seg: 160 bytes de dados
❒ cabeçalho de camada de aplicação adicionado a cada
bloco.
❒ bloco+cabeçalho encapsulado num segmento UDP.
❒ a aplicação envia segmentos UDP para o socket cada 20
mseg durante um trecho de voz.
Internet Phone: Perda de Pacotes e Atrasos
❒ perdas na rede: datagrama IP perdido devido à
congestão na rede (buffer do router cheio)
❒ perda por atraso: datagrama IP chega demasiado
tarde para ser reproduzido no receptor
❍ atrasos: processamento, espera em filas na rede; atrasos
nos sistemas terminais (emissor, receptor)
❍ atraso máximo tolerável típico: 400 ms
❒ tolerante a perdas: dependendo da codificação da
voz, escondendo as perdas, podem ser toleradas
taxas de perdas de pacotes entre 1% e 10%.

Jitter no Atraso
transmissão de
Dados cumulativos
de ritmo recepção
apresentação
constante no cliente
a ritmo constante
no cliente
atraso na
dados em
rede
buffer
variável
atraso de tempo
apresentação
❒ Considere o atraso extremo a extremo entre dois
pacotes consecutivos: a diferença pode ser mais ou
menos que 20 mseg
Internet Phone: Atraso de Apresentação Fixo
❒ O receptor tenta apresentar cada bloco
exactamente q msegs depois de o bloco ser gerado.
❍ o bloco foi gerado no instante t: apresentar o
bloco em t+q .
❍ bloco chega após t+q: os dados chegam
demasiado tarde para serem apresentados,
dados perdidos
❒ Compromissos para q:
❍ q grande: menos perdas de pacotes
❍ q pequeno: melhor interactividade

Atraso de Apresentação Fixo
•O emissor gera pacotes a cada 20 mseg durante um trecho de voz.
O primeiro pacote é recebido no instante r
Primeira hipótese de apresentação: começar em p
Segunda hipótese de apresentação: começar em p
pacotes
pacotes perda
gerados
pacotes
apresentação com atraso de
recebidos
p-r
apresentação com atraso de

p' - r
tempo
r
p p'
Atraso de Apresentação Adaptativo, I
❒ Objectivo: minimizar o atraso de apresentação, mantendo a taxa de
perdas baixa
❒ Aproximação: ajuste do atraso de apresentação adaptativo:
❍ Estimar o atraso da rede, ajustar o atraso de apresentação no início de
cada trecho de voz.
❍ Períodos de silêncio comprimidos ou alongados.
❍ Blocos continuam a ser apresentados a cada 20 mseg durante um trecho
de voz.
t i = tempo em que foi gerado o pacote i
ri = o instante em que o pacote i é recebido no receptor
p i = o instante em que o pacote i é apresentado no receptor
ri − t i = atraso da rede para o pacote i
d i = estimativa do atraso médio da rede depois de receber o pacote i
Estimativa dinâmica do atraso médio no receptor:
d i = (1 − u )d i −1 + u( ri − ti )
onde u é uma constante fixa (e.g., u = 0.01).
Atraso de Apresentação Adaptativo, II
Também é útil estimar o desvio padrão do atraso, vi :
vi = (1 − u )vi −1 + u | ri − ti − d i |
As estimativas di e vi são calculadas para cada pacote recebido, embora
sejam apenas utilizadas no início de um trecho de voz.
Para o primeiro pacote num trecho de voz, o tempo de apresentação é:
pi = ti + d i + Kvi
onde K é uma constante positiva.
Os restantes pacotes do trecho de voz são apresentados periodicamente.
Apresentação Adaptativa, III
Q: Como é que o receptor determina se um pacote é o
primeiro num trecho de voz?
❒ Se não houver perdas, o receptor olha para os
instantes iniciais de pacotes sucessivos.
❍ diferença de instantes iniciais sucessivos > 20 mseg -->
começa trecho de voz.
❒ Quando são possíveis perdas, o receptor tem de
olhar tanto para os instantes iniciais como para os
números de sequência.
❍ diferença de instantes iniciais sucessivos > 20 mseg e
números de sequência sem buracos --> começa um trecho de
voz.

Recuperação de perda de pacotes (1)
forward error correction

❒ O atraso de apresentação
(FEC): esquema simples
tem de ser corrigido para
❒ para cada grupo de n dar tempo de receber todos
blocos, cria um bloco os n+1 blocos
redundante com o OU-

❒ Compromisso:
exclusivo dos n blocos
❍ aumentar n, menos
originais
desperdício de largura de
envia n+1 blocos,
banda
❒
aumentando a largura de
❍ aumentar n, maior atraso
banda por um factor de
de apresentação
1/n.
❍ aumentar n, maior
❒ pode reconstruir os n
probabilidade que 2 ou
blocos originais se perder
mais blocos se percam
no máximo um bloco dos
n+1 blocos Redes Multimédia 6-39
2º esquema FEC fluxo original
acrescentar fluxo de
menor qualidade
redundância
enviar fluxo áudio de
baixa resolução como
informação redundante
por exemplo, fluxo

fluxo
perda
nominal PCM a 64 kbps recebido
e fluxo redundante
GSM a 13 kbps. fluxo
reconstruído
Sempre que há perdas não consecutivas, o receptor
pode esconder a perda.
Para resolver o caso de perdas consecutivas, pode-se
acrescentar os blocos de baixo ritmo (n-1) e (n-2) ao
bloco de ritmo nominal n

fluxo original
fluxo entrelaçado
perda de pacotes
fluxo
reconstruído
Entrelaçamento (Interleaving):
❒ se um pacote é perdido, ainda
❒ os blocos são partidos em
se tem a maior parte de cada
unidades mais pequenas
bloco
❒ por exemplo, 4 unidades de 5
❒ não adiciona redundância
mseg por bloco
❒ mas aumenta o atraso de
❒ um pacote contém unidades mais
apresentação
pequenas de diferentes blocos
Sumário: Multimédia na Internet: saco de truques
❒ usar UDP para evitar o controlo de congestão de TCP
(atrasos) para tráfego sensível ao atraso
❒ atraso de apresentação adaptativo no cliente: para
compensar atrasos
❒ servidor ajusta largura de banda do fluxo à largura de
banda disponível no caminho do servidor para o cliente
❍ escolha entre ritmos de fluxos pré-codificados
❍ ritmo de codificação dinâmico
❒ recuperação de erros (por cima do UDP)
❍ FEC, entrelaçamento
❍ retransmissões, se o tempo permitir
❍ esconder erros: repetir dados próximos


❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP
Real-Time Protocol (RTP)
❒ O RTP especifica uma ❒ O RTP corre nos
estrutura de pacotes sistemas terminais
para pacotes ❒ Os pacotes RTP são

transportando dados encapsulados em
áudio e vídeo segmentos UDP
❒ RFC 1889. ❒ Interoperabilidade: Se
❒ Um pacote RTP oferece duas aplicações
❍ identificação de tipo de Internet phone correm
dados RTP, então pode ser
❍ número de sequência de que possam trabalhar

pacote
em conjunto
❍ marcação de instante de
tempo

RTP corre por cima do UDP
As bibliotecas RTP oferecem uma interface de camada de
transporte que estende o UDP:
número de porto, endereço IP
identificação de tipo de dados
números de sequência de pacotes
marcação de instante de tempo

Aplicação
camada de
transporte
Ligação de Dados
Físico
Exemplo RTP
❒ Considere o envio de
❒ O cabeçalho RTP
voz codificada em PCM
indica o tipo de
a 64 kbps sobre RTP.
codificação áudio em
A aplicação junta os
cada pacote
❒
dados codificados em
❍ o emissor pode mudar a
blocos, e.g., cada 20 codificação durante a
mseg = 160 bytes num sessão.
bloco. ❒ O cabeçalho RTP
❒ O bloco áudio junto também contém
com o cabeçalho RTP números de sequência
forma o pacote RTP, e marcações de
que é encapsulado num instantes de tempo.
segmento UDP.

RTP e QoS
❒ O RTP não oferece nenhum mecanismo para
assegurar a entrega a tempo dos dados ou
oferecer outras garantias de qualidade de serviço.
❒ O encapsulamento RTP é apenas visto nos sistemas
terminais: não é visto pelos routers intermédios.
❍ Os routers que oferecem um serviço melhor esforço
não fazem nenhum esforço especial para assegurar que os
pacotes RTP chegam ao destino a tempo.
Cabeçalho RTP
Tipo de Dados (Payload Type) (7 bits): Indica o tipo de codificação a
ser utilizado. Se o emissor mudar a codificação a meio da sessão, o
emissor informa o receptor através deste campo de tipo de dados.
Tipo de dados 0, PCM mu-law, 64 kbps
Tipo de dados 3, GSM, 13 kbps
Tipo de dados 7, LPC, 2.4 kbps
Tipo de dados 26, JPEG em movimento
Tipo de dados 31, H.261
Tipo de dados 33, vídeo MPEG2
Número de Sequência (Sequence Number) (16 bits): Incrementado de
um por cada pacote RTP enviado, podendo ser utilizado para detectar
perdas de pacotes e para reordenar os pacotes.

Cabeçalho RTP (2)
❒ Campo de marcação de instante de tempo ( Timestamp
field) (32 bits). Reflecte o instante de amostragem do
primeiro byte no pacote de dados RTP.
❍ Para áudio, tipicamente o relógio é incrementado de uma
unidade por cada período de amostragem (por exemplo, a
cada 125 µsegs para uma frequência de amostragem de 8
KHz)
❍ Se a aplicação gera um bloco de 160 amostras
codificadas, então o instante de tempo aumenta de 160
para cada pacote RTP quando a fonte está activa. O
relógio continua a aumentar a um ritmo constante mesmo
quando a fonte está inactiva.
❒ campo SSRC (32 bits). Identifica a fonte do fluxo RTP.
Cada fluxo numa sessão RTP deve ter um SSRC distinto.
Real-Time Control Protocol (RTCP)
❒ Trabalha em conjunto com ❒ As estatísticas incluem
o RTP. número de pacotes
❒ Cada participante numa enviados, número de
sessão RTP periodicamente pacotes perdidos, variação
transmite pacotes de do atraso (jitter), etc.
controlo RTCP para todos ❒ A informação retornada
os outros participantes. pode ser utilizada para
❒ Cada pacote RTCP contém controlar o desempenho
relatórios de emissor e/ou ❍ o emissor pode
receptor modificar as suas
❍ relata estatísticas úteis transmissões com base
para a aplicação na informação
retornada, e.g. mudar o
ritmo de transmissão

RTCP - Continuação
- Para uma sessão RTP tipicamente há apenas um único endereço multicast; todos
os pacotes RTP e RTCP pertencendo à sessão utilizam o endereço multicast.
- Os pacotes RTP e RTCP são distinguidos pela utilização de diferentes números
de portos.
- Para limitar o tráfego, cada participante reduz o seu tráfego RTCP quando o
número de participantes numa conferência aumenta.
Pacotes RTCP
Pacotes de Relatório de Pacotes de descrição da
Receptor: Fonte:
❒ fracção de pacotes ❒ endereço de e-mail do
perdidos, último número emissor, nome do
de sequência, jitter emissor, SSRC do
médio entre chegadas. fluxo RTP associado.
Pacotes de Relatório de ❒ oferece mapeamento
Emissor: entre o SSRC e o nome
do utilizador/sistema
❒ SSRC do fluxo RTP, o
terminal.
instante actual, o
número de pacotes
enviados, e o número de
bytes enviados.

Sincronização de Fluxos
❒ O RTCP pode sincronizar ❒ Cada pacote RTCP de
diferentes fluxos relatório de emissor
multimédia dentro de uma contém (para o pacote mais
sessão RTP. recentemente gerado no
❒ Considere uma aplicação de fluxo RTP associado):
videoconferência onde cada ❍ marcação de instante de
tempo do pacote RTP

emissor gera um fluxo RTP
de vídeo e um de áudio. ❍ hora actual em que o
pacote foi criado.

❒ Marcações de instantes de
Os receptores podem
tempo nos pacotes RTP
❒
utilizar esta associação
associadas aos relógios de
para sincronizar a
amostragem de vídeo e
apresentação de áudio e
áudio
vídeo.
❍ não estão ligados à hora
actual
Divisão de Largura de Banda em RTCP
❒ O RTCP tenta limitar o seu ❒ Os 75 kbps são igualmente
tráfego a 5% da largura de distribuídos pelos receptores:
banda da sessão.
❍ Com R receptores, cada
Exemplo receptor pode enviar tráfego
RTCP a 75/R kbps.

❒ Suponha um emissor,
enviando vídeo ao ritmo de ❒ O emissor pode enviar tráfego
2 Mbps. O RTCP tenta RTCP a 25 kbps.
limitar o seu tráfego a ❒ Um participante determina o
100 kbps. período de transmissão de
❒ O RTCP dá 75% deste pacotes RTCP calculando o
ritmo aos receptores; tamanho médio de um pacote
os restantes 25% ao RTCP (ao longo de toda a
emissor sessão) e dividindo pelo ritmo
atribuído.

SIP
❒ Session Initiation Protocol
❒ vem do IETF - RFC 3261
Visão de longo prazo do SIP:
❒ Todas as chamadas telefónicas e
videoconferências têm lugar sobre a Internet
❒ As pessoas são identificadas por nomes ou
endereços de e-mail, em vez de números de
telefone.
❒ Consegue chegar ao chamado, para onde quer que
ele vá em roaming, seja qual for o equipamento IP
que ele esteja actualmente a utilizar.
Serviços SIP
❒ Estabelecendo uma ❒ Determina o endereço
chamada IP actual do chamador
❍ Oferece mecanismos para ❍ mapeia identificadores
o chamador informar o mnemónicos para o
chamado que quer endereço IP actual
estabelecer uma chamada

❒ Gestão de Chamada
❍ Oferece mecanismos para
❍ Acrescenta novos
o chamador e o chamado
fluxos multimédia
chegarem a acordo sobre
durante a chamada
o tipo de dados e a sua
❍ Muda a codificação
codificação.
durante a chamada
❍ Oferece mecanismos para
❍ Convida outros
terminar a chamada.
❍ Transfere e põe
chamadas em espera

Estabelecendo uma chamada para um endereço IP conhecido
A mensagem SIP de
Alice Bruno
convite (INVITE) da Alice
indica o seu número de
167.180.112.24 193.64.210.89 porto e endereço IP. Indica

INVITE brun
c=IN IP4 16 o@193.64.210.89 a codificação que a Alice
m=audio 38 7.180.112.24
prefere receber (PCM µlaw)
060 RTP/A
VP 0
porto 5060 o terminal
do Bruno
200 OK toca A mensagem 200 OK do
10.89
c=IN IP4 193.64.2 P/AVP 3
m=au dio 48753 RT Bruno indica o seu número
porto 5060
de porto, endereço IP e
codificação preferida
ACK
porto 5060
(3=GSM)
áudio µ Law
Os dados multimédia
porto 38060
podem ser enviadas sobre
GSM TCP ou UDP; aqui enviadas

porto 48753
sobre RTP/UDP.
O porto SIP por omissão é
o 5060.
tempo tempo
Estabelecendo uma chamada (mais)
❒ Negociação do Codec: ❒ Rejeitando a chamada:
❍ Suponha que o Bruno não ❍ O Bruno pode rejeitar
tem um codificador PCM com as respostas
µlaw. ocupado, fui embora,
necessário pagamento,
❍ O Bruno responde com a
proibido.
resposta
606 Not Acceptable ❒ Os dados multimédia podem
e lista os codificadores ser enviados por RTP ou
que pode utilizar. outro protocolo.
❍ A Alice pode então enviar
uma nova mensagem de
INVITE, anunciando um
codificador apropriado.

Exemplo de mensagem SIP
Aqui não sabemos o

INVITE sip:bruno@domain.com SIP/2.0
endereço IP do Bruno.
Via: SIP/2.0/UDP 167.180.112.24
Serão necessário
From: sip:alice@hereway.com servidores SIP
intermediários.
To: sip:bruno@domain.com
Call-ID: a2e3a@pigeon.hereway.com
A Alice envia e recebe
Content-Type: application/sdp
mensagens SIP
Content-Length: 885
utilizando o porto SIP
por omissão de 5060.
c=IN IP4 167.180.112.24

m=audio 38060 RTP/AVP 0 A Alice especifica no
cabeçalho Via: que o

Notas:
cliente SIP envia e
❒ sintaxe de mensagens de HTTP
recebe mensagens SIP
❒ sdp = session description protocol
por UDP
❒ o Call-ID é único para cada chamada.
Tradução de Nomes e localização de utilizadores
❒ O chamador quer
❒ O resultado pode depender
telefonar para um
de:
destinatário, mas apenas
❍ hora do dia (trabalho, casa)
tem o nome ou endereço
❍ chamador (não quer que o
de e-mail do destinatário.
patrão telefone para casa)
❒ Precisa de obter o ❍ estado do chamado (chamadas
endereço IP do sistema enviadas para o voicemail
quando o chamado está a falar

terminal actual do
com alguém)
destinatário:
Serviço oferecido pelos
❍ o utilizador pode mudar de
sítio servidores SIP:
❍ protocolo DHCP ❒ servidor de registo SIP
o utilizador tem vários

servidor proxy SIP
❍
❒
equipamentos IP (PC, PDA,
equipamento no carro)
Registo SIP (SIP Registrar)
❒ Quando o Bruno lança o cliente SIP, o cliente envia uma
mensagem SIP REGISTER para o servidor de registo
do Bruno.
(função semelhante necessária nos serviços de
mensagens instantâneas)
Mensagem de Registo:
REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89
From: sip:bruno@domain.com
To: sip:bruno@domain.com
Expires: 3600
Proxy SIP
❒ A Alice envia mensagens de convite para o seu
servidor proxy
❍ contêm o endereço sip:bruno@domain.com
❒ O proxy é responsável por encaminhar as mensagens
SIP para o chamado
❍ possivelmente através de múltiplos proxys.
❒ O chamado responde através do mesmo conjunto de
proxys.
❒ O proxy retorna a mensagem SIP de resposta para a
Alice
❍ contém o endereço IP do Bruno
❒ Nota: um proxy é análogo ao servidor DNS local

Exemplo
Chamador jim@umass.edu servidor de registo SIP
estabelece uma chamada

upenn.edu
para keith@upenn.edu
servidor de
2 registo SIP
(1) Jim envia uma proxy SIP eurecom.fr
mensagem INVITE para o

umass.edu 3
4
proxy SIP de umass. (2) o
Proxy encaminha o pedido

1 7 5
para o servidor de registo

8
6
da upenn. (3) o servidor da
upenn retorna uma

9
cliente SIP
mensagem de redirecciona- cliente SIP 197.87.54.21
217.123.56.89
mento, indicando que deve
tentar keith@eurecom.fr
(4) o proxy de umass envia o INVITE para o servidor de registo da
eurecom. (5) o servidor de registo da eurecom encaminha o INVITE para
197.87.54.21, que está a correr o cliente SIP do Keith. (6-8) respostas SIP
de volta. (9) dados multimédia enviados directamente entre os clientes.
Nota: também há uma mensagem de ack do SIP, não ilustrada.

Comparação com H.323
❒ O H.323 é outro protocolo de ❒ H.323 vem do ITU
sinalização para interacção em (International
tempo real Telecommunications Union -
❒ O H.323 é um conjunto mundo dos telefones).
completo, verticalmente ❒ SIP vem do IETF: trás
integrado, de protocolos para muitos dos conceitos do
conferências multimédia: HTTP. O SIP tem paladar a
sinalização, registo, controlo Web, enquanto o H.323
de admissão, transporte e tem paladar a telefones.
codecs. ❒ SIP utiliza o princípio
❒ O SIP é um único componente, KISS: Keep it simple
tratando apenas de stupid.
estabelecimento e gestão de
sessões. Trabalha com RTP,
mas não o obriga. Pode ser
combinado com outros
protocolos e serviços. Redes Multimédia 6-64


❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP
Melhorando a QoS em Redes IP
Até agora: obtendo o melhor de um serviço melhor esforço
Futuro: Internet de próxima geração com garantias de QoS
❍ RSVP: sinalização para reserva de recursos
❍ Serviços Diferenciados: garantias de diferença
❍ Serviços Integrados: garantias firmes
❒ modelo simples
Linha de 1.5 Mbps
para estudos de
partilha e
congestão:
Fila de espera da
interface de saída de R1

Princípios para Garantias de QoS
❒ Exemplo: Telefone IP de 1 Mbps e FTP partilham linha de
1.5 Mbps.
❍ rajadas do FTP podem congestionar o router, causar perdas no som
❍ quer-se dar prioridade ao som sobre o FTP
Princípio 1
é necessário marcar os pacotes para o router
distinguir entre diferentes classes; e uma nova política
no router para tratar os pacotes em conformidade
Princípios para Garantias de QoS (mais)
❒ e se as aplicações se portarem mal (som envia a um
ritmo mais elevado do que o declarado)
❍ policiamento: forçar as fontes a aderir às atribuições de
largura de banda
❒ marcação e policiamento na periferia da rede:
❍ tal como no UNI (User Network Interface) do ATM
marcação e policiamento de pacotes
Princípio 2
oferecer a uma classe protecção (isolamento) das outras

❒ Atribuindo uma largura de banda fixa (não
partilhável) a um fluxo: uso ineficiente da largura
de banda se o fluxo não utilizar a sua atribuição
marcação de pacotes
Ligação lógica de 1 Mbps
Ligação lógica de 0.5 Mbps
Princípio 3
Apesar de oferecer isolamento, é desejável
usar os recursos o mais eficientemente possível
❒ Facto básico da vida: não se podem suportar pedidos
de tráfego para além da capacidade da linha
Princípio 4
Admissão de chamada: um fluxo declara as suas
necessidades, a rede pode bloquear a chamada (e.g.,
sinal de ocupado) se não puder servir o pedido

Sumário dos Princípios de QoS
QoS para aplicações em redes
de serviço e policiamento
classificação de pacotes
Admissão de chamadas
Isolamento: mecanismo
alta eficiência
de utilização
De seguida, vamos ver os mecanismos para obter isto

❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP

Mecanismos de Serviço e Policiamento
❒ mecanismo de serviço (scheduling): escolher o próximo
pacote a enviar para a linha
❒ serviço FIFO (first in first out): envia pela ordem de
chegada à fila
❍ exemplo do mundo real?
❍ política de descarte: se um pacote chega a uma fila cheia: quem
descartar?
descarte da cauda (Tail drop): descarta o pacote que chega
por prioridade: descarta/remove com base na prioridade
aleatória: descarta/remove aleatoriamente
chegadas partidas
fila de espera linha

(servidor) Redes Multimédia 6-73
Políticas de Serviço: mais
Serviço com prioridade (Priority scheduling): transmite
o pacote de maior prioridade da fila de espera
❒ múltiplas classes, com diferentes prioridades
❍ classe pode depender da marcação ou outra informação do
cabeçalho, e.g. origem/destino IP, número de porto, etc.
❍ exemplo do mundo real?
fila de espera
de alta prioridade
chegadas
tempo
chegadas
pacote em
serviço
classificar partidas
linha tempo
(servidor) partidas
fila de espera
de baixa prioridade

Políticas de Serviço: ainda mais
serviço round robin:
❒ múltiplas classes
❒ percorre ciclicamente as filas de espera das
classes, servindo um de cada classe (se houver)
❒ exemplo do mundo real?
chegadas tempo
pacote em
serviço
partidas tempo
Políticas de Serviço: ainda mais
Weighted Fair Queuing:
❒ generalização do Round Robin
❒ cada classe obtém uma determinada proporção de
serviço em cada ciclo
❒ exemplo do mundo real?
classificar
chegadas linha
partidas

Mecanismos de Policiamento
Objectivo: limitar o tráfego para não exceder os
parâmetros declarados
Três critérios frequentemente utilizados:
❒ Ritmo médio (longo prazo): quantos pacotes podem ser
enviados por unidade de tempo (no longo prazo)
❍ questão crucial: qual é o intervalo de tempo: 100 pacotes por
seg ou 6000 pacotes por min têm a mesma média !
❒ Ritmo de pico: e.g., 6000 pacotes por minuto em
média; ritmo de pico de 1500 pacotes por segundo
❒ Tamanho (máximo) de rajada (burst): máximo número
de pacotes enviado consecutivamente (sem paragens
pelo meio)
Mecanismos de Policiamento
Balde furado: limitar a entrada ao tamanho de rajada
e ritmo médio especificados.
balde guarda até

b tokens
pacotes espera
token
para a
rede
❒ o balde pode guardar b tokens
❒ tokens gerados ao ritmo de r tokens/seg a menos que
o balde esteja cheio
❒ num intervalo de tempo t: número de pacotes
admitidos menor ou igual a (r t + b).

Mecanismos de Policiamento (mais)
❒ balde furado, WFQ combinam para oferecer um
limite máximo garantido para o atraso, i.e., garantia
de QoS !
tráfego ritmo de tokens, r
que chega
tamanho do balde, b
ritmo por
fluxo, R
WFQ
D = b/R
max
Atraso Máximo: para o caso de o balde ter b tokens, e chegar uma
rajada (instantânea) de b pacotes


❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP

Serviços Integrados do IETF
❒ arquitectura para oferecer garantias de QoS em
redes IP para sessões de aplicações individuais
❒ reserva de recursos: os routers mantêm
informação de estado (a la VC) dos recursos
atribuídos, requisitos de QoS
❒ admitir/recusar novos pedidos de estabelecimento
de chamada:
Questão: pode um novo fluxo ser admitido com
garantias de desempenho sem violar as garantias
de QoS dadas aos fluxos já admitidos?
IntServ: cenário de garantias de QoS
❒ Reserva de recursos
❍ estabelecimento de chamada,
sinalização (RSVP)
❍ declaração do tráfego, QoS
❍ controlo de admissão por elemento
pedido/
resposta
❍ serviço sensível à
QoS (e.g., WFQ)

Admissão de Chamada
Uma sessão que chegue deve:
❒ declarar os seus requisitos de QoS
❍ R-spec (Reservation): define a QoS que é pedida
❒ caracterizar o tráfego que vai enviar para a rede
❍ T-spec (Traffic): define as características do
tráfego
❒ protocolo de sinalização: necessário para levar o
R-spec e T-spec para os routers (onde as reservas
são necessárias)
❍ RSVP
Admissão de Chamada
❒ Admissão de Chamada: os routers aceitam as
chamadas com base nas suas R-spec e T-spec e
com base nos recursos correntemente atribuídos
nos routers para outras chamadas.
1. Pedido: especifica
- tráfego (Tspec)
- requisitos de QoS (Rspec)
3. Resposta: o pedido pode

ou não ser aceite
2. Elemento considera
- recursos não reservados
- recursos solicitados

QoS IntServ : Modelos de Serviço [RFC 2211, RFC 2212]
Serviço Garantido: Serviço de Carga Controlada:
❒ chegada de tráfego no pior caso: ❒ uma qualidade de serviço
fonte policiada por balde furado próxima da QoS que o mesmo
fluxo receberia de um elemento

❒ limite simples (demonstrado
da rede não carregado."
matematicamente) para o atraso
[Parekh 1992, Cruz 1988]
tráfego ritmo de tokens, r
que chega
tamanho do balde, b
ritmo por
fluxo, R
WFQ
D = b/R
max

❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP

Resource ReSerVation Protocol - RSVP
❒ Permite fazer reservas de recursos (e.g. largura de banda)
❒ Tem de estar presente nos receptores, emissores e
routers
❒ Permite reservas em árvores multicast (o unicast é tratado
como um caso particular do multicast)
❒ Orientado para o receptor: o receptor inicia e mantém as
reservas de recursos
fluxo de dados
reservas reservas
fundidas fundidas
mensagem
de reserva
RSVP: Exemplo
❒ Suporta codificação Reserva:

dos fluxos em
100 Kbps
camadas. fonte
Eg. ritmo base:
Reserva:
3 Mbps
20 Kbps, resolução
melhorada: 100 Kbps
❒ Reservas fundidas no Reserva:

3 Mbps
caminho para o
emissor
❒ Teste de admissão de
chamada: se não for
possível, é enviado um
erro para o receptor

RSVP: Segundo Exemplo
❒ Videoconferência com canais de 3 Mbps
❒ Cada pessoa quer ver as outras 3
❒ Reservas de 9 Mbps numa direcção, 3 Mbps na
outra
emissor/receptor
emissor/receptor emissor/receptor
emissor/receptor
RSVP: usa Soft State
❒ Os routers mantêm estado sobre as reservas
❒ Têm de haver mensagens periódicas de refrescamento
❒ Sem refrescamento, o estado é limpo após um certo
tempo
❒ Alternativa: hard state
❍ Sem mensagens de refrescamento periódicas
❍ Garante-se que o estado está lá
❍ O estado é mantido até ser explicitamente removido
❍ Porque pode haver problemas?
❒ Propriedades do soft state:
❍ Adapta-se a mudanças nos caminhos, fontes e receptores.
❍ Recupera de falhas
❍ Limpa o estado se um receptor sair


❒ 6.9 Serviços
Internet Phone
Diferenciados
de Tempo Real
❍ RTP, RTCP
❍ SIP
Serviços Diferenciados do IETF
Preocupações com IntServ:
❒ Escalabilidade: sinalização, manter estado nos routers
por cada fluxo difícil com grande número de fluxos
❒ Modelos de Serviço Flexíveis: IntServ tem apenas duas
classes. Também se quer classes de serviço qualitativas
❍ comporta-se como um cabo
❍ distinção de serviço relativa: Platina, Ouro, Prata
Aproximação DiffServ:
❒ funções simples no núcleo da rede, funções
relativamente complexas nos routers da periferia (ou
sistemas terminais)
❒ Não definir classes de serviço, oferecer componentes
funcionais para construir classes de serviço

Arquitectura DiffServ
Router na periferia: marcação

r scheduling
- gestão do tráfego por fluxo
- marca pacotes como dentro de
perfil e fora de perfil

b ..
.
Router no núcleo:
- gestão do tráfego por classe
- espera em filas e serviço baseado
na marcação feita na periferia
- dada preferência a pacotes
dentro de perfil
- classe de envio assegurado
(Assured Forwarding)
Marcação de Pacotes num Router da Periferia
❒ perfil: ritmo A, tamanho de balde B pré-negociados
❒ marcação de pacotes na periferia com base num perfil por fluxo
Ritmo A
Pacotes do utilizador
Utilizações possíveis da marcação:
❒ marcação baseada na classe: pacotes de diferentes classes marcados de
forma diferente
❒ marcação dentro da classe: parte do fluxo conforme com o perfil
marcada de forma diferente da parte não conforme

Classificação e Condicionamento
❒ O pacote é marcado no campo Type of Service
(TOS) em IPv4, e Traffic Class em IPv6
❒ 6 bits são utilizados para o código de serviço
diferenciado (Differentiated Service Code Point,
DSCP) e determinam o PHB (Per-Hop Behaviour)
que o pacote vai receber
❒ 2 bits estão actualmente não utilizados (Currently
Unused)
Classificação e Condicionamento
Pode ser desejável limitar o ritmo de injecção de tráfego
de alguma classe:
❒ o utilizador declara o perfil de tráfego (eg, ritmo,
tamanho de rajada)
❒ o tráfego é medido, suavizado se não estiver conforme
medidor
enviar
suavizador/
classificador marcador
descartador
pacotes
descartar

Mecanismo de Envio (PHB)
❒ Cada PHB resulta num comportamento com
desempenho de envio observável (que pode ser
medido) diferente
❒ Um PHB não especifica que mecanismos utilizar
para assegurar o comportamento com o
desempenho requerido
❒ Exemplos:
❍ Classe A obtém x% da largura de banda de saída da linha,
medida em intervalos de tempo de duração especificada
❍ Os pacotes da classe A partem em primeiro lugar, antes
dos pacotes da classe B
Mecanismo de Envio (PHB)
PHBs em desenvolvimento:
❒ Envio Expedito (Expedited Forwarding): taxa de
partidas de pacotes é igual, ou excede, o ritmo
especificado
❍ ligação lógica com ritmo mínimo garantido, semelhante a
um cabo
❒ Envio Assegurado (Assured Forwarding): 4 classes
de tráfego
❍ cada uma tem uma fracção mínima da largura de banda
❍ cada uma com três prioridades para controlar o descarte

Redes Multimédia : Sumário
❒ aplicações multimédia e requisitos
❒ obtendo o melhor do serviço melhor
esforço actual
❒ mecanismos de serviço e policiamento
❒ Internet da próxima geração: IntServ,
RSVP, DiffServ

6 Redes Multimedia

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

6 Redes Multimedia

Enviado por

Direitos autorais:

Formatos disponíveis

Multimédia, Qualidade de Serviço (QoS): O que são?

áudio e vídeo pela rede

Redes Multimédia 6-1

❒ Classificar aplicações multimédia

❒ Identificar os serviços da rede que as aplicações

❒ Obtendo o melhor de um serviço melhor esforço

❒ Mecanismos para oferecer QoS

❒ Protocolos específicos para melhor esforço

❒ Arquitecturas para QoS

Redes Multimédia 6-2

❒ 6.1 Aplicações de Rede ❒ 6.5 Para além do Melhor

❒ 6.2 Fluxos de áudio e ❒ 6.6 Mecanismos de

vídeo armazenados Serviço e Policiamento

❍ RTSP ❒ 6.7 Serviços Integrados

❒ 6.3 Multimédia de Tempo ❒ 6.8 RSVP

Real: Estudo do caso do

❒ 6.4 Protocolos para

Redes Multimédia 6-3

Aplicações de Rede Multimédia

Jitter é a variação dos ❒ Antítese da transmissão

Redes Multimédia 6-4

❒ dados armazenados na fonte

❒ transmitidos para o cliente

❒ fluxos: o cliente começa a

apresentação antes de todos

❒ restrições temporais para os dados ainda por

transmitir: a tempo para serem apresentados

Redes Multimédia 6-5

Fluxos Multimédia Armazenados:

fluxo: neste instante, o cliente

apresenta a parte inicial do vídeo,

enquanto o servidor ainda envia a parte

Redes Multimédia 6-6

❒ funcionalidade tipo gravador de vídeo:

o cliente pode fazer pausa, recuar,

avançar, saltar para outra parte

❍ atraso inicial de 10 seg OK

❍ 1-2 seg até o comando actuar OK

❍ uso frequente de RTSP (mais em breve)

❒ restrições temporais para os dados ainda por

transmitir: a tempo para serem apresentados

Redes Multimédia 6-7

Fluxos Multimédia ao Vivo

❒ Espectáculo de rádio via Internet

❒ Transmissão directa de evento desportivo

❒ a apresentação pode atrasar-se dezenas de

segundos depois da transmissão

❒ ainda tem restrições temporais

❒ voltar atrás, pausa possíveis!

Redes Multimédia 6-8

❒ aplicações: telefone IP,

❍ áudio: < 150 mseg bom, < 400 mseg OK

 inclui atrasos da aplicação (enpacotamento) e da rede

 atrasos mais elevados notados, prejudicam interactividade

❍ como o chamado anuncia o seu endereço IP, número

de porto, algoritmos de codificação?

Redes Multimédia 6-9

Multimédia na Internet de Hoje

TCP/UDP/IP: serviço melhor esforço

❒ sem garantias no atraso, perdas

precisavam de QoS e de um certo nível ?

As aplicações multimédia na Internet de hoje

usam técnicas na camada de aplicação para

minimizar (o melhor possível) os efeitos dos

inclui atrasos da aplicação (enpacotamento) e da rede

atrasos mais elevados notados, prejudicam interactividade

TCP/UDP/IP: serviço melhor esforço

❒ sem pipelining, longos atrasos até à apresentação!