QoS em
Redes
QoS em
Redes
Paulo
Aguiar
NCE/IM
UFRJ
Conteúdo
Conteúdo
Motivação: novas
aplicações e necessidades de QoS (2h)
Análise de TCP e
configuração de parâmetros para
desempenho
(2h)
Noções de teoria
de filas e técnicas ativas de gerenciamento de
buffer
(2h)
Arquiteturas de
QoS: Serviços Integrados (RSVP) e Serviços
Diferenciados
(4h)
QoS em rede
local: recomendações e exemplos (1h)
Políticas de
priorização de filas em roteadores (4h)
Implantação de
QoS para VOIP: recomendações de boa prática
(2h)
Prática:
laboratório de QoS (2h)
Prova:
(2h)
Prática:
Laboratório de QoS
Prática:
Laboratório de QoS
Configuração de
QoS em roteadores: aula
preparatória
Desempenho de
VoIP em ambiente com e sem QoS
– Ativação de diferentes políticas de filas (FCFS, WFQ,
PQ)
em roteadores e
switches de uma rede local, avaliando o
desempenho para
tráfego prioritário e não prioritário
Motivação para
QoS
Motivação para
QoS
Evolução nos
últimos anos
– Processadores poderosos de baixo
custo
– Sistemas de disco de grande largura de banda (RAID) com
banda de
Gbps
– Sistemas
gráficos
(1024x1024x32) a
30 fps = 1 Gbps
– Uso amplo de fibras óticas
– Telefonia digital
– Arquitetura de redes e interconexão em alta
velocidade
Resultado
– Equipamentos em condições de gerar alto
tráfego
– Necessidade de suportar integração de serviços
Evolução nas
Corporações
Evolução nas
Corporações
Cenários
– Manipulação de Informação
digitalizada
– Voz e vídeo
Vídeo e
teleconferência
Telefonia sobre
IP
– VPNs corporativas
– Acesso remoto de alta velocidade entre filial e matriz
ou
para acesso
individual a recursos centralizados da
corporação
Pressão de
demanda de banda e qualidade nos
backbones dos
provedores
Informação
Digitalizada
Informação
Digitalizada
Cheque
digitalizado
40-80
kbps
Gráfico não
comprimido 256 kbps
Ressonância
magnética 1,5 Mbps
Chapa de
raios-X
8
Mbps
Documentos de
seguro
50
Mbps
Vídeo e
Teleconferência
Vídeo e
Teleconferência
HDTV sem
compressão: 1,5 Gbps
HDTV, formato
interim: 360 Mbps
SDTV (SMPTE):
270 Mbps
MPEG-2
comprimido: 25-60 Mbps
MPEG-2 (HDTV de
difusão): 19,4 Mbps
SDTV (MPEG-2): 6
Mbps
MPEG-1: 1,5
Mbps
MPEG-4: 5 kbps –
4 Mbps
H.323 (H.263):
28 kbps – 1 Mbps
Telefonia na
Rede
Telefonia na
Rede
Arquiteturas
– PBXs conectados via gateways IP
– Voz sobre IP (VOIP)
– Soft PBXs
Codecs
– G.723.1 (5,3 Kbps ACELP) -6,3 Kbps
MLQ)
– G.729, G.729A (8 Kbps CS-ACELP)
– G.728 (16 Kbps LD-CELP)
– G.711 (64 Kbps
PCM)
Impacto na rede
pode ser significativo se um número
elevado de
sessões de voz ocorrer simultaneamente
Qualidade da voz
sensível a jitter, atraso e perdas
Aplicações IP
Avançadas
Aplicações IP
Avançadas
Colaboração
interativa de alta qualidade
Acesso em tempo
real a recursos remotos, como
microscópios e
telescópios
Colaboração em
larga escala entre centros
científicos,
envolvendo data mining e computação
distribuída
Realidade
virtual compartilhada
Aplicações de
data grid: computação distribuída
– Biológica, médica, geofísica, física,
etc
Requisitos de
Banda
Requisitos de
Banda
10-100
kbps
Telefonia
150 Mbps – 1
Gbps
TV de alta
definição
1 Mbps- 1
Gbps
Acesso
multimídia a
banco de
dados
1-10
Gbps
Computação
distribuída
10-100
Mbps
Visualização
interativa
1-10
Mbps
Teleconferência
Internet/Intranet
Internet/Intranet
Usos
– Usuários com acesso em alta
velocidade
– Tráfego Web interativo
– Aplicações baseadas em Web
– Arquitetura P2P (Peer-to-Peer)
– Aplicações baseadas em
servidor
Consequência
– Geram pacotes grandes e são potenciais provocadores de
congestionamento
nos pontos de concentração de tráfego
Pacote Web ≈ 1
Kbytes
– Pequenos pacotes de tráfego interativo, com pouca
demanda de
banda, acabam sofrendo atrasos inesperados
Síntese
Síntese
Voz é uma
aplicação vital em qualquer
cenário dos
próximo anos
– Killer application
Tráfego de
tempo real terá que conviver com
altas taxas de
transferências das outras
aplicações em
pequenos ou longos intervalos
de
tempo
Desafio para a
rede convergente
– Como garantir a qualidade de serviço para os
tráfegos
críticos?
Requisitos de
QoS para Áudio
Interativo
Requisitos de
QoS para Áudio
Interativo
RTT limitado
(< 300 ms, recomendação do ITU-T )
Baixa banda por
sessão
– Compressão e supressão de silêncio podem diminuir ainda
mais a banda
utilizada
– Codecs de maior complexidade exigem mais poder
computacional
G.723 (alta) –
G.729 (alta) – G.728 (média) – G.711 (baixa)
Baixo
jitter
– Buffer de compensação de jitter nas pontas prejudica
interatividade,
pois conta no RTT
Baixa
perda
– Qualquer perda afeta a qualidade
percebida
– Desejável abaixo de
1%
Requisitos de
QoS para Vídeo
Interativo
Requisitos de
QoS para Vídeo
Interativo
Dependem do
tipo de aplicação, se crítica ou não
Uma operação
médica a distância tem requisitos
extremos de
qualidade do vídeo e do aúdio
– Baixíssima perda, baixo jitter, atraso
limitado
– Requisitos de banda dependerão do formato e do tamanho
da tela de
vídeo sendo transmitida, mas nessas aplicações
será
elevado
Uma
teleconferência pode suportar perdas eventuais
de pacotes de
vídeo sem prejudicar
substancialmente a
aplicação
– Baixa perda, baixo jitter, atraso
limitado
– Qualidade inferior do vídeo requer menor
banda
Produto
Delay x Bandwidth
(PDB)
Produto
Delay x Bandwidth
(PDB)
Representa a
quantidade mínima de bits que
devemos ter em
transmissão sem confirmação para
termos chance
de alcançar a banda máxima
– Em redes locais, PDB = 10K a 50K
bits
atraso = 1 ms,
banda = 10 Mbps a 50 Mbps
– Na WAN, PDB = 400K bits
atraso = 200
ms, banda = 2 Mbps
– Na WAN de alta velocidade, PDB = 4M
bits
atraso 200ms,
banda = 20 Mbps
Boa prática
recomenda que espaço em buffer em
roteadores
intermediários seja pelo menos o PDB
para a
conexão
PDB alto pode
prejudicar desempenho de protocolos
que não foram
desenvolvidos para este cenário
O que pode dar
errado na rede?
O que pode dar
errado na rede?
Tipos de
Falhas
– Erro a nível de bit
– Falhas nos enlaces e nos
nós
Fila em
congestionamento
– Atrasos altos
– Jitter alto
– Perda de pacotes ou
quadros
Controle de
Congestionamento
Controle de
Congestionamento
Se entrada de
tráfego não é controlada
– Filas nos enlaces congestionados crescem
– Espaço nos buffers acaba
– Pacotes são descartados
– Retransmissões provocam mais congestionamento, vazão
tende a zero e
posso cair em deadlock
vazão
deadlock
overhead de
controle
carga
oferecida
Controle de
Congestionamento
Controle de
Congestionamento
Opções
– Pré-alocar recursos para evitar
congestionamento
– Envie dado e … tente minimizar
congestionamento
Router
Fast
E
thern
et
10 Mbps
Ethernet
2 Mbps
E1
Fonte
1
Destino
Fonte
2
Controle de
Congestionamento
Controle de
Congestionamento
Implementação
em dois pontos
– No host na ponta (protocolo de
transporte)
– Nos roteadores dentro da
rede
Implementações
– Centrada no roteador versus centrada no
host
– Baseada em reserva versus baseada em
feedback
– Baseada em janela versus baseada em
taxa
feedback
Transmissão de
Dados
Transmissão de
Dados
TCP protocolo
padrão
Tráfego TCP
corresponde a mais de 80% do
tráfego de uma
rede multimídia típica
– FTP, HTTP, SMTP, SNMP,
etc
Comportamento
do TCP crucial para
determinar
congestionamento nas filas dos
roteadores
TCP
TCP
Usa o conceito
de janela deslizante
Tenta gerar
incrementar sempre a banda
ofertada,
aumentando o tamanho da janela
de transmissão
à medida que recebe
confirmações
(ACKs)
Assume que
pacotes são raramente
corrompidos por
erros e que perda é devida a
congestionamento
Usa mecanismo
de feedback, reduzindo a
janela de
transmissão face a indícios de
congestionamento
ACK
ACK
Sempre que um
pacote é recebido no
destino, um ACK
é retornado, confirmando os
bytes recebidos
recebidos corretamente e em
seqüência
– O ACK carrega na realidade a indicação do
próximo byte
esperado
Funcionamento
do TCP
Funcionamento
do TCP
Sempre que um
pacote é transmitido, um time-out é
disparado
Quando ack do
pacote chega, time-out é inibido
Quando um
pacote é perdido e os subseqüentes
chegam ao
destino, acks duplicados são gerados,
solicitando a
retx do pacote não recebido
A chegada de
acks duplicados força a retx do pacote
perdido,
cancelando estouro do time-out
Reação a Perda
Reação a Perda
A perda
eventual de um pacote, que é
sentida pela
recepção de três acks
duplicados,
força a redução da oferta de
tráfego a
metade
O estouro de um
time-out indica um forte
congestionamento
(perda de pacotes em
rajada) e força
a conexão TCP a reiniciar
com oferta de
banda mínima
Comportamento
do TCP
Comportamento
do TCP
Vazão ocorre em
dente de serra
– Quando há congestionamento, vazão é reduzida
drasticamente,
entrando em Slow Start
Referência
– RFC2001, TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and
Fast Recovery Algorithms, Janeiro 1997
Congestion
window
Kbytes
tempo
Time-out
três acks
duplicados
Controle do
TCP
Controle do
TCP
Duas janelas de
controle e um threshold
– Advertised Receiver Window Size (recwnd)
Limitada pelo
buffer de recepção no destino
Valor inicial
Informado na abertura da conexão TCP
(SYN)
– Congestion window (cwnd)
Inicializada
com 1 (MSS bytes)
– Threshold
Inicializado em
65535 bytes
Controle do
TCP
Controle do
TCP
Janelas e acks
referenciados em termos de
bytes e usam
unidades do tamanho máximo
de segmento
– Maximum segment size (MSS)
MSS limitado
pelo MTU (maximum
transmission
unit) para evitar fragmentação
– Procedimentos de MTU
discovery
Em qualquer
instante, a janela de
transmissão
(txwnd) = mín {recwnd, cwnd}
Princípios do
TCP
Princípios do
TCP
Procedimentos
básicos
– Slow start
– Congestion avoidance
– Fast retransmit
Slow Start e
Congestion
Avoidance
Slow Start e
Congestion
Avoidance
Slow
Start
– Inicia com cwnd =1 (MSS)
– Incrementa cwnd a cada ack
recebido, ou seja cresce
exponencialmente até
alcançar threshold, entrando em
congestion
avoidance
– Durante slow start temos cwnd < threshold
Congestion
Avoidance
– A partir daí aumenta linearmente, incrementando de 1
(MSS) a cada
RTT, ou seja, ao receber um ack incrementa
cwnd de
1/cnwd
Incremento de
cwnd pode não ser suficiente para permitir o
envio de um
pacote naquele instante
– Em congestion avoidance, cwnd > threshold
Importância do
Cálculo do RTO
Importância do
Cálculo do RTO
Se o time-out
for menor do que o RTT real na
rede, haverá
retransmissão desnecessária;
Se o time-out
for muito grande em relação ao
real, em caso
de congestionamento severo, a
reação a este
congestionamento será mais
lenta, pois
dependerá do time-out.
Cálculo do
RTO
Cálculo do
RTO
A cada ACK
recebido, pode-se calcular o RTT
instantâneo M,
que é o tempo entre o envio de um
pacote pelo
TxTCP e o recebimento do ACK
correspondente;
– Y = M - A
– D ← D + 0,25 * (|Y| - D)
– A ← A + 0,125 * Y
– RTO = A + 4D
Inicialmente, A
= 0, D = 0 e M igual a RTT medido
pelas
primitivas iniciais de SYN
Nas fórmulas
acima, A é o valor suavizado do RTT e
D é o valor
suavizado do desvio médio.
Cenário
Esperado
Cenário
Esperado
O cálculo de
RTO espera que a variação de
RTT seja grande
na rede
Caso RTT tenha
pequenas variações apenas
num tempo
longo, RTO tende a se aproximar
do RTT
instantâneo
– Tempo de propagação grande e pequenas filas
nos hops
intermediários
– Nestas condições, qualquer atraso repentino na
chegada de um
ACK acarreta estouro do RTO
Comportamento
Adicional do
TCP
Comportamento
Adicional do
TCP
Um novo valor
de recwnd no receptor pode
ser repassado a
fonte num pacote de ACK, a
qualquer
instante durante uma sessão TCP
Nas
implementações, para minimizar tráfego,
ACKs são
atrasados e um único ACK pode
confirmar dois
pacotes recebidos
corretamente
Problemas com
TCP
Problemas com
TCP
Tráfego nos
roteadores chega em rajadas e
descarte
simultâneo ocorre nas conexões
TCP
compartilhando o gargalo
– Ocorre sincronização global
– Todos reagem no mesmo instante reduzindo a
banda;
eventualmente todos passam por Slow
Start
– Tráfego no enlace oscila, utilização do link cai e
vazão
individual de cada TCP fica abaixo da fatia
equânime
(fair share) esperada
Problemas com
TCP
Problemas com
TCP
Congestionamento
afetando muitas ( > 100)
conexões TCP
pode levar a ineqüidade na
captura da
banda
– Algumas conexões recebem bem mais do que
outras em um
tempo longo
– Referência: R. Morris, TCP Behavior with Many
Flows, IEEE
International Conference on
Networks,
Outubro 1997
Problemas com
TCP
Problemas com
TCP
Sempre
incrementando alocação de banda e,
conseqüentemente,
possibilidade de
congestionamento
Retransmissões
frente a congestionamento só
realimentam o
processo de degradação
Vazão
prejudicada quando perdas devido ao meio
são
interpretadas como congestionamento
– Ambiente de redes sem fio (redes wireless)
Quando RTT é
elevado (ex.: satélite), realimentação
é lenta e retx
gera ineficiência
– Usar FEC é solução
Detalhes de
TCP
Detalhes de
TCP
Detecção de
Congestionamento
Detecção de
Congestionamento
Congestionamento é
detectado por time-out ou
recepção de
acks duplicados
Ocorrência de
ACKs duplicados
– Pacote é perdido, mas pacotes subseqüentes chegam ao
destino,
gerando acks iguais e duplicados, indicando que o
pacote perdido
é o próximo a ser esperado no receptor
Causas de
time-out
– Perda de pacotes consecutivos, impedindo que acks sejam
gerados no
destino
– Perda de acks consecutivos na rota reversa, do destino
à
fonte
Reação a Acks
Duplicados
Reação a Acks
Duplicados
Quando o
primeiro ack duplicado chega, nada
acontece no
transmissor
Quando o
terceiro ack duplicado é recebido, o pacote
faltante é retx
(Fast Retransmit), faz threshold =
txwnd/2
e passa a usar cwnd=threshold + 3
Enquanto ack
deste pacote não chega, cwnd
aumenta de 1 a
cada novo ack duplicado recebido
Os outros
pacotes enviados estão sendo armazenados no
destino para
entrega, após o pacote faltante chegar
Após chegada do
ack esperado (após RTT), fazemos
cwnd=threshold
e entramos em congestion
avoidance
Exemplo Passo a
Passo
Exemplo Passo a
Passo
A fonte inicia
operando com cwnd=w, e os pacotes
[u,u+w-1]
são
transmitidos
Temos w
pacotes em trânsito e acks chegarão após RTT;
assuma que
apenas o pacote u se perde
Receptor envia
ack (u) a cada pacote recebido (do u+1 em
diante),
indicando que ainda espera receber o pacote u; serão
w-1 acks
a serem enviados
– Pacotes fora de ordem no receptor são armazenados, sem
serem
repassados para
a aplicação
Ao receber os
três primeiros acks duplicados, a fonte retx o
pacote u
e faz threshold= w/2 e cwnd=w/2 + 3
Enquanto o ack
referente ao pacote u não retorna, a fonte irá
incrementar
cwnd de 1 a cada ack duplicado recebido
Exemplo Passo a
Passo
Exemplo Passo a
Passo
Ao final da
recepção dos w-4 acks duplicados pendentes, temos
cwnd =
w/2+3+w-4 = w + w/2 - 1, permitindo que os pacotes
[u,u+w+w/2-2]
tenham sido transmitidos;
– Destes, apenas w/2 –1 pacotes são realmente
transmitidos, pois os
w pacotes [u,
u+w –1] já haviam sido transmitidos
anteriormente
– As chegadas dos primeiros w/2 acks duplicados então
serve para
dar tempo ao
gargalo para esvaziar a fila
Ao chegar o ack
(u+w), que confirma do pacote u ao pacote
u+w-1, a fonte
faz threshold = cwnd = w/2 e passa a operar
em congestion
avoidance
Os pacotes sem
confirmação são [u+w,u+w+w/2-2] e os que
estão na janela
de transmissão são [u+w, u+w+w/2-1],
permitindo a
transmissão do pacote (u+w+w/2-1), que é
exatamente o
pacote que ainda não foi transmitido
A partir deste
ponto as transmissões são retomadas gradual e
corretamente
pelo mecanismo do congestion avoidance
Reação a
Time-out no
Transmissor
Reação a
Time-out no
Transmissor
Retransmite
pacote, faz threshold =
txwnd/2,
cwnd = 1 e entra em Slow Start
Implementações
de TCP, em geral, tratam
um time-out por
vez para um mesmo pacote
Se outros
pacotes já transmitidos
anteriormente
dentro da janela estouram o
time-out, eles
serão retransmitidos e o TCP
repete o
procedimento acima, forçando nova
diminuição do
threshold
Exemplo:
Estouro de
Temporizador ou
Time-Out (RTO)
Exemplo:
Estouro de
Temporizador ou
Time-Out (RTO)
Suponha
txwnd=cwnd= w, ou seja, pacotes [u, u+w-1], estão
pendentes num
certo instante e a recepção de acks é interrompida,
apesar dos
pacotes terem chegado OK no destino
RTO (u)
estoura e pacote u é retx, entrando em slow start com
cwnd = 1,
threshold = w/2 e janela de transmissão =
[u,u]
– Observe que a janela de transmissão
recua
Suponha que
RTO (u+1) estoure
– Numa implementação inteligente, como o pacote (u+1)
está fora da janela,
este estouro
pode ser ignorado, evitando entrar novamente em slow start
com cwnd =
[u,u] e threshold = w/4.
Com RTOs
estourando sucessivamente, caso não procedamos como
indicado, o
threshold iria baixar exponencialmente até atingir 1, quando
passaríamos a
operar com cwnd=threshold=1
– Situação drástica que pode ocorrer com RTT alto e com
pequena variância
de atraso,
provocando uma estimativa de RTO muito próxima ao RTT real
A chegada do
ack (u+w), fará o TCP entrar em congestion avoidance,
com cwnd=2,
janela = [u+w, u+w+1] e threshold=w/2, que é adequado
Referências
para TCP
Referências
para TCP
Stevens, W.
Richard, TCP/IP Illustrated, Volume 1 The Protocols,
Addison-Wesley,
576 páginas, 1994
RFC-793,
Transmission Control Protocol, 1981
RFC-1323, RCP
Extensions for High Performance, 1992
RFC-2001, TCP
Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast
Recovery Algorithms, 1997
RFC-2018, TCP
Selective Acknowledgement Options,1996
RFC-2581, TCP
Congestion Control, 1999
RFC-3168, The
Addition of Explicit Congestion Notification (ECN) to IP,
2001
RFC-3360,
Inappropriate TCP Resets Considered Harmful, 2002
RFC-3390,
Increasing TCP's Initial Window, 2002
RFC-3449, TCP
Performance Implications of Network Path Asymmetry,
2002
RFC-3481, TCP
over Second (2.5G) and Third (3G) Generation
Wireless
Networks, 2003 |