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

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)

Asignar ancho de banda

fijo (no compartible) al

flujo: uso ineficiente del ancho de banda si el flujo

no usa su asignacin

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

(Mx.) Tamao de Rfaga: mx. Nmero de paqs.

ppm para peak

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

balde este lleno

r token/seg a menos que el

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 [rfc2211, rfc 2212]

Servicio garantizado:

Servicio de carga Controlada:

peor caso de trfico de llegada:

"una calidad de servicio

fuente con balde por goteo

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

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
Tasa de audio:

Slo un rbol de ruta multicast posible

H3

H2
R1

R2

H1
H5

R3

H4

RSVP: creando el estado del trayecto

H1, , H5 envan mensajes de trayecto en

m1:

(address=m1, Tspec=b, filter-spec=no-filter,refresh=100)

Sponer que H1 enva primero el mensaje de trayecto

m1:

m1:

in L1
out
L2 L6

in
L7
out L3 L4

L6
m1: in
out L5
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

m1:

L6
L1
m1: in
out L1 L2 L6

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

m1:

L1 L2 L6
m1: in
out L1 L2 L6

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
;H4-via-R2 (b))
)
)

L4, L7

L3(H4-via-H4 ; H1-via-R2
out L4(H1-via-R2 )
L7(H4-via-H4 (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
;H4-via-R2 (b))
)
)

L4, L7

L3(H4-via-H4 ; H1-via-R3
out L4(H1-via-62 )
L7(H4-via-H4 (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
;H4-via-R2 (b))
)
)

L4, L7

L3(H4-via-H4 ; H1-via-R3
out L4(H1-via-62 )
L7(H4-via-H4 (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!