Você está na página 1de 51

QoS (Quality of Service)

Multimedia
en red

Computer Networking: A Top


Down Approach Featuring the
Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2002.

Multimedia, Quality of Service: qu es?


Multimedia aplicaciones:
audio y video en red
(continuous media)

QoS
La red ofrece aplicaciones
con nivel de desempeo
necesario para que la
aplicacin funcione

Aplicaciones MM en red
Clases aplicaciones MM:
1) Streaming stored
audio&video
2) Streaming live
audio&video
3) Real-time interactive
audio&video

Jitter es la variabilidad
de los retardos de
paquetes en mismo
stream de paquete

Caractersticas
fundamentales :
Tpicamente sensitivo
retardo de

end-to-end
jitter

Pero tolerante a prdida:

prdidas infrecuentes
causan complicaciones
menores
Anttesis de los datos data,
que son intolerantes a
prdidas pero tolerantes a
retardos.

Multimedia Streaming almacenado

Streaming:
Almacenado en la fuente
Transmitido al cliente
streaming: el despliegue en el
cliente empieza antes de que
lleguen todos los datos
Restricciones de tiempo para los datos

que est aun por ser transmitidos y ya


estn siendo desplegados

Cumulative data

Streaming Multimedia almacenado:


qu es?

1. video
recordado

2. video
Tx

retardo
de red

3. video recivido,
y desplegado en el
cliente
time

streaming: en este momento, el cliente


est desplegando, mientras el servidor
est aun transmitiendo el resto

Streaming Multimedia almacenado:


Interactividad

Funcionalidad tipo VCR: el cliente


puede pausar, rebobinar, FF
10 seg. retardo inicial OK
1-2 seg. hasta el efecto del
comando OK
RTSP usado a menudo

Streaming Multimedia en vivo


Ejemplos:
Internet radio
Eventos deportivos en lnea
Streaming
playback buffer
playback puede almacenar decenas de segundo
despus de la transmisin
Todavia hay restricciones de tiempo
Interactividad
fast forward imposible
rewind, pause posible!

Multimedia Tiempo Real Interactiva

aplicaciones: telefona IP, video

conferencia

Requerimientos de retarto extremo a extremo:

audio: < 150 mseg bueno, < 400 mseg OK


incluye nivel de aplicacin (paquetizacin) y retardos de red
Retardos ma altos notorios, interactividad no par

Iniciliazacin de sesin

Cmo puede el que es llamado hacer publica su IP,


nmero de puerto, algoritmos de codificacin?

Multimedia sobre la Internet de hoy


TCP/UDP/IP: servicio de mejor esfuerzo

No hay garantas de retardo y prdidas

Pero las apps multimedia requieren ?


QoS y nivel de desempeo para ser efectivas

Las aplicaciones multimedia de Internet de


hoy usan tcnicas a nivel de aplicacin para
mitigar (lo mejor posible) efectos

Mejorando QOS en redes IP


Por lejos: hacer lo mejor de lo mejor en esfuerzo
Futuro: prxima generacin Internet con garantas QoS
RSVP: signaling for resource reservations
Servicios diferenciados: garantas diferenciales
Servicios Integrados: garantas
Modelo simple para
estudios de
comparticin
y congestin :

Principio para garantas de QOS


Ejemplo: telfono 1Mbps I P, FTP comparten enlace 1.5

Mbps.

rfagas de FTP pueden congestionar el router, pedidas de audio


Se requiere dar prioridad al audio sobre FTP

Principio 1
Se necesita una construccin de paquetes para que el
router distinga entre clases; y una poltica de router
para tratar los paquetes de manera concordante

Principio para garantas de QOS (2)


Qu pasa si la aplicacin se comporta mal (audio enva a

una tasa mayor que la declarada)

poltica: forzar a la fuente a adherirse a las asignaciones de BW

Marcar y aplicar polticas en la periferia de la red

Principio 2
Proveer proteccin (aislamiento) a una clase respecto de las otras

Principio para garantas de QOS (3)


fijo (no compartible) al
flujo: uso ineficiente del ancho de banda si el flujo
no usa su asignacin

Asignar ancho de banda

Principio 3
Mientras se provee aislamiento es deseable usar los
recursos lo ms eficientemente posible

Principio para garantas de QOS (4)

Hecho bsico: no se puede soportar trfico ms


all de la capacidad del enlace

Principio 4
Admisin de llamada: el flujo declara sus necesidades,
la red puede bloquear la llamada (ej.:, marcar ocupado)
si no puede suplir sus necesidades

Sumario de los principios de QoS

Echemos una mirada a los mecanismos para lograr esto .

Mecanismos de Scheduling y Polticas


scheduling: elegir el prximo paquete para ser enviado

por el enlace
Scheduling FIFO (first in first out): enviar en el orden
de llegada a la cola

Poltica de descartado: si un paquete llega a una cola llena:


cual descartar?
Tail drop: descartar el paquete que llega
priority: descartar/remover en base a prioridad
random: descartar/remover randmicamente

Polticas de Scheduling
Priority scheduling: transmitir el paquete de la cola
que tiene la mayor prioridad
mltiples clases, con diferentes prioridades

Clases dependen de las marcas u otra informacin del


header, Ej.: IP fuente/destino, nmero de puerto etc.

Polticas de Scheduling (2)


Scheduling round robin:
mltiples clases
Cclicamente se recorren las colas de clases,
sirviendo una de cada clase (si hay disponibles)

Polticas de Scheduling (3)


Weighted Fair Queuing:
Round Robin generalizado
cada clase obtiene una cantidad de servicio con un

peso (weighted) en cada ciclo

Mecanismos para Polticas


Meta: limitar el trfico para no exceder los parmetros
declarados
Tres criterios usados comnmente:
(Long term) Tasa Media: cuantos paquetes se ha
enviado por unidad de tiempo (por un largo rato)

Preguntas cruciales: cual es el largo del intervalo: 100


paquetes por seg. o 6000 paquetes por mn. tienen el mismo
promedio!

Tasa Peak: ej., 6000 paq. por mn. (ppm) medio.; 1500
ppm para peak
(Mx.) Tamao de Rfaga: mx. Nmero de paqs.
Enviados consecutivamente (sin intermedio ocioso)

Mecanismos para Polticas (2)


Balde de Token: limitar la entrada a un tamao de
rfaga y tasa media especificado.

balde puede contener b tokens


tokens generados a tasa

r token/seg a menos que el

balde este lleno


En un intervalo de largo t: nmero de paquetes
admitidos es menor o igual a (r t + b).

Mecanismos para Polticas (3)


Balde de token, WFQ combinados para proveer

lmite superior para retardo limitado, es decir,


garanta de QoS !

Trfico
entrante

Tasa de token, r
Tamao de balde, b

WFQ

tasa, R
por flujo

D = b/R
mx

Servicios Integrados IETF


arquitectura para proveer garantas QOS en redes IP para

sesiones de aplicacin individuales


Reserva de recursos: los routers mantienen informacin de
estado de los recursos asignados, requerimientos QoS
admitir/denengar nuevos requerimientos de llamadas:

Pregunta: puede ser admitido un flujo nuevo con


garantas de desempeo y no violar las garantas
QoS hechas a los flujos ya admitidos?

Intserv: escenario de garanta QoS


Reserva de recursos
Establecimiento de llamada,
sealizacin (RSVP)
trafico, declaracin de QoS
Control de admisin por elemento

request/
reply

QoS-sensitive
scheduling (e.g.,
WFQ)

Admisin de llamadas
Las sesiones nuevas deben :
declarar sus requerimientos QOS

R-spec: definir la QOS que es requerida


Caracterizar el trfico que enviara a ala red
T-spec: definir las caractersticas de trfico
Protocolo de sealizacin: necesario para
transportar R-spec y T-spec a los routers (donde la
reserva es requerida)
RSVP

Intserv QoS: modelos de servicio

Servicio de carga Controlada:

Servicio garantizado:
peor caso de trfico de llegada:

fuente con balde por goteo


Lmite simple (matemticamente
probable) en el retardo [Parekh
1992, Cruz 1988]
Trfico
entrante

[rfc2211, rfc 2212]

"una calidad de servicio

aproximada a la QoS que el


mismo flujo recibe de un
elemento de red descargado."

Tasa de token, r
Tamao de balde, b

WFQ

tasa, R
por flujo

D
= b/R
mx

Servicios diferenciados IETF


Intserv:
Escalabilidad: sealizacin, difcil mantener estado por
flujo en el router para muchos flujos
Modelos de Servicio Flexibles: Intserv tiene slo dos
clases. Tambin clases de servicios cualitativos

comportamiento como cable


Distincin de servicio relativo : Platinum, Gold, Silver

Enfoque Diffserv:
Funciones simples en el ncleo de la red, funciones
relativamente complejas en los routers perifricos (o
hosts)
No define clases de servicio, provee componentes
funcionales para construir las clases de servicios

Arquitectura Diffserv
Router de borde:

r marcar
scheduling

- administracin de trfico por-flujo


- marca paquetes como in-profile o
out-profile

router de ncleo:
- administracin de trfico por clase
- buffering y scheduling basado en
marcar al borde
- preferencia a paquetes in-profile
- Forwarding asegurado

..
.

Marcado de paquetes en router de borde


profile: tasa A, tamao del balde B pre-negociados
Marcado de paquetes al borde basado en perfil por-flujo

Tasa A
B
Paquetes de usuario

Posible uso de marca:


Marcado basado en clases: paquetes de diferentes clase marcados en

forma diferente
Marcado intra-class: porcin de trfico conformado marcado
diferentemente que el no conformado

Clasificacin y Condicionamiento
Paquete marcado en Tipo de Servicio (TOS) en

IPv4, Clase de Trfico en IPv6


6 bits usados para Diferentiated Service Code
Point (DSCP) y determinar PHB que el paquete
recibir
2 bits no usados

Clasificacin y Condicionamiento (2)


Puede ser deseable limitar la inyeccin de trfico de
algunas clases:
Usuarios declararan perfil de trfico (ej. tasa,
tamao de rfaga)
Trfico medido, conformado si no est conformado

MPLS (MultiProtocol Label Switching)


Definido en RFC 3031
Diferentes mtodos de forwarding
Similar a VCs (ATM, FR, etc.)
Llamado tambien label switching, tag switching
Nuevo header de mensaje (a.k.a tag):
20 bits label
3 bits QoS
1 bit S (stacking)
8 bits TTL
Soporta agregacin de tags llamados FEC

(forwarding equivalence class)

Construccin de MPLS VC
Enfoque orientado a Data: VC es inicializado por

demanda en forma recursiva

Posible problema de loops

Enfoque orientado a Control: cuando el router hace

boots crea labels para el destino en sus tablas de


rutas

Sealizacin en Internet
Sin conexin
(sin estado)
forwarding por medio
de routers IP

Servicio de
mejor
esfuerzo

En diseo inicial
de IP: no hay
protocolos de
sealizacin de
red

Nuevos requirimientos: reserva de recursos en rutas

extremo a extremo (sistemas finales, routers) para


QoS en aplicaciones multimedia
RSVP: Resource Reservation Protocol [RFC 2205]

permite a los usuarios comunicar requerimientos a la red en


de manera robusta. es decir, sealizacin !

Primer protocolo de sealizacin Internet: ST-II [RFC

1819]

Metas de diseo RSVP

acomodar receptores heterogneos (diferentes


anchos de banda en el trayecto)
acomodar diferentes aplicaciones con diferentes
requerimientos de recursos
Hacer de multicast un first class service, con
adaptacin a grupos de multicast
Apoyo en el ruteo existente multicast/unicast, con
adaptacin a cambios en unicast subyacente, rutas
multicast
Protocol de control de overhead para crecer (al
menos) linealmente en # de receptores
Diseo modular para tecnologas subyacentes
heterogneas

RSVP: no hace
Especificar cmo los recursos son reservados

En cambio: un mecanismo para comunicar


necesidades

determinar rutas que los paquetes tomarn

Es el trabajo de los protocolos de ruteamiento

Sealizacin desacoplada del ruteo

interactuar con forwarding de paquetes

separacin de los planos de control (sealizacin) y


data (forwarding)

RSVP: operacin
unin a un grupo multicast de transmisores y receptores
Fuera de RSVP
Transmisores no necesitan unirse a prupo
Sealizacin transmisor a red
Mensaje de trayecto: hacer que los routers conozcan la presencia
de los transmisores
Deshacer trayecto: borrar transmisores del estado de trayectos
de los routers
Sealizacin receptor a red
mensaje de reserva: reserva recursos desde transmisor(es) a
receptor(es)
Deshacer trayecto: remover reservaciones del receptor
Sealizacin red a sistemas finales
Error en trayecto
Error de reservacin

Msgs de trayecto: sealizacin RSVP transmisor a red


los mensaje de trayecto contienen:

address: unicast de destino, o grupo multicast


flowspec: spec requerimientos de ancho de banda.
filter flag: if yes, guardar identidades del de
transmisor (para permitir filtrado de paquetes en la
fuente)
previous hop: upstream router/host ID
refresh time: hasta que esta informacin time out
Mensaje de trayecto: comunica informacin de
transmisor, e informacin de ruteo del trayecto
receptor-transmisor

RSVP: conferencia simple audio


H1, H2, H3, H4, H5 tanto transmisores como receptores
Grupo multicast m1
no filtrado: reenvo de paquetes de cualquier transmisor

b
Slo un rbol de ruta multicast posible
Tasa de audio:

H3

H2
R1

R2

H1
H5

R3

H4

RSVP: creando el estado del trayecto


m1:
(address=m1, Tspec=b, filter-spec=no-filter,refresh=100)
Sponer que H1 enva primero el mensaje de trayecto
H1, , H5 envan mensajes de trayecto en

m1:

in L1
out
L2 L6

m1:
m1: in
out L5

in
L7
out L3 L4

L6
L7

H3

H2

L3

L2

H1

L1

R1

L6

R2
L5

H5

L7

R3

L4

H4

RSVP: creando el estado del trayecto


luego, H5 enva el mensaje de trayecto, creando ms estados

en los routers

L6
L1
m1: in
out L1 L2 L6

m1:

in
L7
out L3 L4

L5 L6
m1: in
out L5 L6 L7

H3

H2

L3

L2

H1

L1

R1

L6

R2
L5

H5

L7

R3

L4

H4

RSVP: creando el estado del trayecto


H2, H3, H5 envan mensajes de trayecto, completando las

tablas de estado

L1 L2 L6
m1: in
out L1 L2 L6

m1:

in L3 L4 L7
out L3 L4 L7

L5 L6 L7
m1: in
out L5 L6 L7

H3

H2

L3

L2

H1

L1

R1

L6

R2
L5

H5

L7

R3

L4

H4

Msgs de reservacin: seales receptor a red


Los mensajes de reservacin contienen:
Ancho de banda deseado
Tipo de filtro:
no filter: cualquier paquete al grupo multicast puede usar la
reserva
fixed filter: slo paquetes desde un conjunto especfico de
transmisores puede usar la reserva
dynamic filter: transmisores cuyos paquetes pueden ser
reenviados por el enlace (a eleccin del receptor) en el tiempo.

especificacin de filtro spec

Reservaciones desde el receptor para flujo del

transmisor, que crea, estado relacionado al receptor


en los routers

RSVP: reservacin de receptor ejemplo 1


H1 desea recibir audio de todos los otros transmisores
H1 mssg reservacin a las fuentes por el rbol
H1 slo reserva recursos pra 1 audio stream
Reservacin es de tipo no filter cualquier transmisor

puede usar el ancho de banda reservado

H3

H2

L3

L2

H1

L1

R1

L6

R2
L5

H5

L7

R3

L4

H4

RSVP: reservacin de receptor ejemplo 1


H1 msgs reservacin a las fuentes por el rbol
routers, hosts reservan ancho de banda b necesario

para el enlace a H1
m1: in L1 L2
out L1(b) L2

L6
L6

m1:

L2

H1

b
b
L1

R1

b
L6

L7
L7(b)

L7
L6
L6(b) L7

m1: in L5
out L5

H2

L4
L4

in L3
out L3

R2
L5

H5

b
L7

R3

L3
b
L4

H3

H4

RSVP: reservacin de receptor ejemplo 1


luego, H2 hace reservacin no-filter para ancho de banda
H2 reenva a R1, R1 reenva a H1 y R2 (?)
R2 no hace nada, porque

b ya estaba reservado en L6

L6
m1: in L1 L2
out L1(b) L2(b) L6

m1:

b
L2

H1

b
b
b L1

R1

b
L6

L7
L7(b)

L7
L6
L6(b) L7

m1: in L5
out L5

H2

L4
L4

in L3
out L3

R2
L5

H5

b
L7

R3

L3
b
L4

H3

H4

RSVP: ejemplo 2
H1, H4 son slo transmisores
envan mensajes de trayecto como antes, indicando b
reservacin filtrada
Routers almacenan transmisores upstream por cada enlace
upstream
H2 desea recibir de H4 (slo)
H3

H2

L3

L2

H1

L1

R1

L6

R2

L7

R3

L4

H4

RSVP: ejemplo 2
H1, H4 slo transmisores
envan mensajes de trayecto como antes, indicando
reservacin filtrada
in

L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2

in

; H4-via-R2
)
)

L4, L7
L3(H4-via-H4
out L4(H1-via-R2
L7(H4-via-H4

; H1-via-R3
)
)

H3

H2

R2

L2

H1

L1

R1

L7

L6
in

L3

R3

L6, L7

L6(H4-via-R3
out L7(H1-via-R1

)
)

L4

H4

RSVP: ejemplo 2
receptor H2 enva mensaje de reservacin para fuente

H4 al ancho de banda b

Propagado upstream a H4, reservando b

in

L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2

H2
L2

H1

in

L4, L7
L3(H4-via-H4 ; H1-via-R2
out L4(H1-via-R2 )
L7(H4-via-H4 (b))

;H4-via-R2 (b))
)
)

H3

b
L1

R1

b
L6
in

R2

b
L7

L6, L7

L6(H4-via-R3 (b))
out L7(H1-via-R1 )

R3

L3
b
L4

H4

RSVP: soft-state
Tx peridicamente revean msgs de trayecto para refrescar estado
Rx peridicamente revean msgs resv para refrescar estado
trayecto y msgs resv tienen campo TTL, para intervalo de refresco
in

L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2

H2
L2

H1

in

L4, L7
L3(H4-via-H4 ; H1-via-R3
out L4(H1-via-62 )
L7(H4-via-H4 (b))

;H4-via-R2 (b))
)
)

H3

b
L1

R1

b
L6
in

R2

b
L7

L6, L7

L6(H4-via-R3 (b))
out L7(H1-via-R1 )

R3

L3
b
L4

H4

RSVP: soft-state
suponga H4 (Tx) abandona sin realizar su retiro formal
eventualmente el estado en routers har timeout y desaparecer!

in

L1, L6
L2(H1-via-H1
out L6(H1-via-H1
L1(H4-via-R2

H2
L2

H1

in

L4, L7
L3(H4-via-H4 ; H1-via-R3
out L4(H1-via-62 )
L7(H4-via-H4 (b))

;H4-via-R2 (b))
)
)

H3

b
L1

R1

b
L6
in

R2

b
L7

L6, L7

L6(H4-via-R3 (b))
out L7(H1-via-R1 )

R3

L3
b
L4

Se fue a
H4
pescar!