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!
