MATERIAL DE ESTUDIO

1. Queueing: Colas de Procesamiento
Poner algo en cola es almacenarlo en orden, a la espera de ser procesado. En una red de
ordenadores, cuando se envían paquetes desde un anfitrión, éstos entran en un sistema de
colas en el que permanecen hasta ser procesados por el sistema operativo. Entonces el
sistema operativo decide qué cola debe procesar y qué paquete o paquetes de dicha cola. El
orden en el que el sistema operativo selecciona los paquetes que va a procesar puede afectar
al rendimiento de la red. Pongamos por ejemplo un usuario que estuviera ejecutando dos
aplicaciones de red: SSH y FTP. Lo ideal sería procesar los paquetes de SSH antes que los
de FTP, por la propia naturaleza de SSH; cuando se pulsa una tecla en el cliente SSH se
espera obtener una respuesta inmediata, mientras que un retraso de unos pocos segundos en
una transferencia por FTP pasa casi inadvertido. Pero, ¿qué ocurriría si el enrutador que
maneja estas conexiones procesara una gran parte de paquetes de la conexión de FTP antes
de procesar la conexión de SSH? Los paquetes de la conexión de SSH se quedarían en la
cola (o incluso serían rechazados por el enrutador si la cola no fuera lo suficientemente
grande como para mantener todos los paquetes) y podría parecer que hay retrasos en la
sesión de SSH, o que va muy lenta. Al modificar la estrategia de la cola en uso, las diversas
aplicaciones, usuarios y ordenadores pueden compartir bastante bien el ancho de banda de
la red.
Nótese que el uso de colas sólo es de utilidad para paquetes con dirección de salida, desde
dentro. Una vez que un paquete ha llegado a una interfaz desde fuera, es demasiado tarde
para ponerlo en una cola debido a que ya habrá consumido el ancho de banda necesario
para llegar a la interfaz que acaba de recibirlo. En estos casos la única solución es activar el
sistema de colas en el enrutador adyacente o, si el anfitrión que ha recibido el paquete actúa
como enrutador, activar el sistema de colas en la interfaz interna desde la que los paquetes
salen del enrutador.
Schedulers:
El scheduler es lo que decide qué colas hay que procesar y en qué orden deben ser
procesadas. Por definición, OpenBSD usa un scheduler tipo FIFO (el primero en entrar es
el primero en salir). Una cola FIFO funciona como la cola de un supermercado o la de un
banco, en donde el primer producto de la cola es también el primero que se procesa. Según

2. van llegando nuevos paquetes, éstos se van añadiendo al final de la cola. Si la cola se llena,
los nuevos paquetes que vayan llegando van siendo bloqueados. Esto se conoce como "tail-
drop".
OpenBSD tiene soporte para dos schedulers adicionales:
Colas Basadas en Clases (Class Based Queueing)
Colas Basadas en Prioridades (Priority Queueing)
Colas Basadas en Clases
CBQ (Class Based Queueing) es un algoritmo de formación de colas que divide el ancho de
banda de una conexión de red entre varias colas o clases. A cada cola se le asigna un tráfico
basándose en la dirección de origen o de destino, el número de puerto, protocolo, etcétera.
De forma opcional, se puede configurar una cola para que tome prestado ancho de banda de
la cola matriz de la cual origina, si ésta está siendo infrautilizada. A las colas también se les
da una prioridad de modo que aquellas que contengan tráfico interactivo, como SSH,
puedan tener sus paquetes procesados antes que las colas que contengan tráfico masivo,
como FTP.
Las colas CBQ se ordenan de un modo jerárquico. En la parte superior de la jerarquía se
encuentra la cola matriz, que define la cantidad total de ancho de banda disponible. Las
colas derivadas de ésta se crean bajo la cola matriz, y a cada una de ellas se les puede
asignar alguna porción del ancho de banda de la cola matriz. Por ejemplo, se pueden definir
las colas como sigue:
Cola Matriz (2Mbps)
Cola A (1Mbps)
Cola B (500Kbps)
Cola C (500Kbps)
En este caso, el ancho de banda total disponible se ha configurado a 2 megabits por
segundo (Mbps), que luego se divide entre las tres colas derivadas.
La jerarquía se puede expandir aún más definiendo colas dentro de otras colas. Para dividir
el ancho de banda en partes iguales entre varios usuarios y clasificar también el tráfico de
éstas con el fin de evitar que ciertos protocolos agoten el ancho de banda de otros, se puede
definir una estructura de formación de colas como la siguiente:
Cola Matriz (2Mbps)

3. UsuarioA (1Mbps)
ssh (50Kbps)
tráf. masivo (950Kbps)
UsuarioB (1Mbps)
audio (250Kbps)
tráf. masivo (750Kbps)
http (100Kbps)
otro tráfico (650Kbps)
Nótese que, en cada nivel, la suma del ancho de banda asignado a cada una de las colas no
es superior al ancho de banda asignado a la cola matriz.
Se puede configurar una cola para que tome prestado ancho de banda de la cola de la que
origina, si le sobra ancho de banda debido a que no está siendo utilizado por otras colas
derivadas. Tomemos como ejemplo una configuración de formación de colas como la
siguiente:
Cola Matriz (2Mbps)
UsuarioA (1Mbps)
ssh (100Kbps)
ftp (900Kbps, préstamo)
UsuarioB (1Mbps)
Si el tráfico en la cola de ftp excede los 900Kbps y el tráfico en la cola del UsuarioA es
menor de de 1Mbps (debido a que la cola de ssh está usando menos tráfico que los
100Kbps asignados), la cola de ftp tomará prestado el ancho de banda sobrante del
UsuarioA. De este modo, la cola de ftp podrá usar más ancho de banda del que tiene
asignado cuando sufra una sobrecarga. Cuando la cola de ssh incremente su carga, se
devolverá el ancho de banda que se ha tomado prestado.
CBQ asigna a cada cola un nivel de prioridad. Las colas con una prioridad más alta tendrán
preferencia sobre las colas de prioridad más baja durante una congestión, ya que ambas
colas comparten la misma matriz de origen (o sea, siempre que ambas colas se encuentren
en la misma rama dentro de la jerarquía). Las colas con una misma prioridad se procesan
del modo round-robin. Por ejemplo:
Cola Matriz (2Mbps)

4. UsuarioA (1Mbps, prioridad 1)
ssh (100Kbps, prioridad 5)
ftp (900Kbps, prioridad 3)
UsuarioB (1Mbps, prioridad 1)
CBQ procesará las colas del UsuarioA y del UsuarioB del modo round-robin; ninguna de
las dos colas tendrá preferencia sobre la otra. Al mismo tiempo que esté procesando la cola
del UsuarioA, CBQ también procesará las colas que deriven de ésta. En este caso, la cola
de ssh tiene una prioridad más alta y obtendrá un trato preferente sobre la cola de ftp si hay
congestión en la red. Nótese que no se comparan las prioridades de las colas de ssh y ftp
con las colas del UsuarioA y UsuarioB, ya que no están en la misma rama dentro de la
jerarquía.
Para una explicación más detallada de la teoría detrás de CBQ, véanse estas Referencias
sobre CBQ.
Colas Basadas en Prioridades
Las PRIQ (Priority Queueing) asignan colas múltiples a una interfaz de red, y dan a cada
cola un nivel de prioridad único. Una cola con un nivel de prioridad más alto se procesa
siempre antes que una cola con un nivel de prioridad más bajo.
La estructura de formación de colas en PRIQ es estricta, y no se pueden definir colas dentro
de otras colas. Se define sólo la cola matriz, en la que se decide la cantidad total de ancho
de banda disponible y, a partir de ahí, las «sub-colas» se definen bajo la cola matriz.
Consideremos el siguiente ejemplo:
Cola Matriz (2Mbps)
Cola A (prioridad 1)
Cola B (prioridad 2)
Cola C (prioridad 3)
La cola matriz está definida con un ancho de banda de 2Mbps disponible para sí misma, y
se han definido tres subcolas. La cola con la prioridad más alta (el número de prioridad más
alto) es la que se procesa primero. Una vez que se han procesado todos los paquetes en esa
cola, o si la cola estuviera vacía, PRIQ pasa a la cola que tenga el siguiente nivel de
prioridad más alto. Dentro de una cola cualquiera, los paquetes se procesan del modo FIFO.

5. Es importante tener en cuenta que cuando se usa PRIQ hay que planificar las colas con
mucho cuidado. Debido a que PRIQ siempre procesa una cola de prioridad más alta antes
que otra de prioridad más baja, es posible que una cola de alta prioridad sea la causa de que
se retrasen, o incluso se lleguen a bloquear, paquetes en una cola de prioridad más baja si la
cola de alta prioridad está recibiendo un flujo constante de paquetes.
Pronta Detección Aleatoria
RED (Random Early Detection) es un algoritmo que se utiliza para evitar la congestión. Su
trabajo es evitar la congestión en la red, asegurándose de que la cola no se llene. Para ello
calcula constantemente la longitud media (el tamaño) de la cola y la compara con dos
umbrales o límites, un umbral mínimo y otro máximo. Si el tamaño medio de la cola se
encuentra por debajo del umbral mínimo, entonces no se bloqueará ningún paquete. Si el
tamaño medio se encuentra por encima del umbral máximo, entonces todos los paquetes
nuevos que lleguen serán bloqueados. Si el tamaño medio se encuentra entre los valores de
los dos umbrales, entonces se bloquearán los paquetes de acuerdo con un cálculo de
probabilidad obtenido a raíz del tamaño medio de la cola. En otras palabras, según se va
aproximando el tamaño medio de la cola al umbral máximo, se va bloqueando un número
cada vez mayor de paquetes. Cuando bloquea los paquetes, RED escoge de qué conexiones
bloqueará los paquetes de una forma aleatoria. Las conexiones que usen mayores
cantidades de ancho de banda serán las que tengan una probabilidad más alta de que se
bloqueen sus paquetes.
RED es muy útil por que evita una situación conocida como sincronización global,
explosiones repentinas de tráfico (desbordamientos). La sincronización global se refiere a
una pérdida total de caudal debida al bloqueo de paquetes desde varias conexiones al
mismo tiempo. Por ejemplo, si la congestión tiene lugar en un enrutador que lleva tráfico
para 10 conexiones de FTP y se están bloqueando los paquetes de todas estas conexiones (o
de la mayoría de ellas), como ocurre con la formación de colas tipo FIFO, el caudal total
caerá de forma significativa. Esta situación no es deseable por que provoca que todas las
conexiones de FTP reduzcan su caudal, y también implica que la red ya no puede ser
utilizada en su potencia máxima. RED evita esta situación escogiendo de forma aleatoria
las conexiones cuyos paquetes bloqueará, en lugar de escogerlas todas. Las conexiones que
usen grandes cantidades de ancho de banda tienen una mayor probabilidad de que sus

6. paquetes sean bloqueados. De esta forma se moderará el ritmo de las conexiones que usen
un mayor ancho de banda, se evitará la congestión, y no habrán pérdidas significativas en el
caudal total. Además de esto, RED también puede manejar explosiones repentinas de
tráfico, ya que empieza a bloquear paquetes antes de que se llene la cola. Cuando llega una
explosión de tráfico no hay espacio suficiente en la cola para contener los nuevos paquetes.
RED sólo se debería usar cuando el protocolo de transporte fuera capaz de responder a los
indicadores de congestión de la red. En la mayoría de casos esto significa que RED se
debería usar para poner en cola el tráfico TCP, y no el tráfico UDP o ICMP.
Notificación Explícita de Congestión
ECN (Explicit Congestion Notification) funciona en conjunción con RED para notificar a
dos anfitriones que se comuniquen a través de la red sobre cualquier congestión existente
en el camino de la comunicación. Para ello permite que RED active un indicador en la
cabecera del paquete, en lugar de bloquear el paquete. Si el anfitrión remitente tiene soporte
para ECN, entonces puede leer este indicador y moderar el ritmo del tráfico de su red en
consecuencia.
Configuración de la Formación de Colas
Desde la versión 3.0 de OpenBSD, la implementación ALTQ (Alternate Queueing) de
formación de colas ha formado parte del sistema base. Desde OpenBSD 3.3, ALTQ se ha
integrado en PF. La implementación de ALTQ de OpenBSD tiene soporte para schedulers
de Colas Basadas en Clase (CBQ) y Colas Basadas en Prioridades (PRIQ). También tiene
soporte para Pronta Detección Aleatoria (RED) y Notificación Explícita de Congestión
(ECN).
Debido a que ALTQ ha sido fusionado con PF, es necesario activar PF para que funcione la
formación de colas. Las instrucciones para la activación de PF se pueden encontrar en la
sección de Primeros Pasos.
La formación de colas se configura en pf.conf. Existen dos tipos de directivas usadas para
configurar la formación de colas:
altq on - activa la formación de colas en un interfaz, define el scheduler que se usará, y crea
la cola matriz
queue - define las propiedades de una cola derivada
La sintaxis para la directiva altq on es:

7. altq on interface scheduler bandwidth bw qlimit qlim
tbrsize size queue { queue_list }
interface - la interfaz de red en la que se vaya a activar la formación de colas.
scheduler - el scheduler que se usará para la formación de colas. Los valores que acepta son
cbq y priq. Sólo se puede activar un scheduler en una interfaz al mismo tiempo.
bw - la cantidad total de ancho de banda disponible para el scheduler. Se puede especificar
como un valor absoluto usando los sufijos b, Kb, Mb y Gb para representar bits, kilobits,
megabits, y gigabits por segundo respectivamente, o como porcentaje del ancho de banda
de interface.
qlim - el número máximo de paquetes que puede contener la cola. Este parámetro es
opcional, y la configuración predeterminada es de 50.
size - el tamaño del regulador de prueba en bytes. Si no se especifica, el tamaño se
configurará basándose en el ancho de banda de interface.
queue_list - una lista de las colas derivadas que se crearán bajo la cola matriz.
Por ejemplo,
altq on fxp0 cbq bandwidth 2Mb queue { std, ssh, ftp }
activa CBQ en la interfaz fxp0. El ancho de banda total disponible está configurado en
2Mbps. Se han definido tres colas derivadas: std, ssh y ftp.
La sintaxis para la directiva queue es:
queue name [on interface] bandwidth bw [priority pri] [qlimit qlim]
scheduler ( sched_options ) { queue_list }
name - el nombre de la cola. Debe coincidir con el nombre de una de las colas definidas por
queue_list en la directiva altq on. Para cbq, también puede coincidir con el nombre de una
cola definida por queue_list en la directiva queue anterior. Los nombres de las colas no
deben exceder los 15 caracteres.
interface - la interfaz de red en la que la cola es válida. Este valor es opcional, y cuando no
se especifique la cola será válida en todas las interfaces.
bw - la cantidad total de ancho de banda disponible para la cola. Se puede especificar como
un valor absoluto usando los sufijos b, Kb, Mb, y Gb para representar bits, kilobits,

8. megabits, y gigabits por segundo respectivamente, o como porcentaje del ancho de banda
de la cola principal. Este parámetro sólo es aplicable cuando se usa el scheduler cbq.
pri - la prioridad de la cola. Para cbq el rango de prioridad va de 0 a 7, y para priq el rango
va de 0 a 15. La prioridad 0 es la más baja. Si no se especifica, se usará un valor
predeterminado de 1.
qlim - el número máximo de paquetes que puede contener la cola. Si no se especifica, se
usará un valor predeterminado de 50.
scheduler - el scheduler que se utilice, ya sea cbq o priq. Debe ser el mismo que para la
cola matriz.
sched_options - opciones adicionales que se pueden pasar al scheduler para controlar su
comportamiento:
default - define una cola predeterminada a la que irán todos los paquetes que no coincidan
con ninguna otra cola. Es necesaria la definición de al menos una cola predeterminada.
red - activa RED en esta cola.
rio - activa RED con IN/OUT. En este modo, RED mantendrá tamaños medios de cola
múltiples y valores de umbrales múltiples, uno por cada nivel de Calidad de Servicio de IP
(IP Quality of Service).
ecn - activa ECN en esta cola. ecn implica red.
borrow - la cola puede tomar ancho de banda prestado de su cola matriz. Esto sólo se puede
especificar cuando se usa el scheduler cbq.
queue_list - una lista de colas derivadas que se crearán bajo esta cola. Una queue_list sólo
se puede definir cuando se usa el scheduler cbq.
Continuando con el ejemplo anterior:
queue std bandwidth 50% cbq(default)
queue ssh { ssh_login, ssh_bulk }
queue ssh_login priority 4 cbq(ecn)
queue ssh_bulk cbq(ecn)
queue ftp bandwidth 500Kb priority 3 cbq(borrow red)
Aquí se encuentran activados los parámetros de las colas derivadas anteriormente definidas.
A la cola stq se le ha asignado un ancho de banda del 50% del ancho de banda de la cola
matriz (ó 1Mbps), y está configurada como la cola predeterminada. La cola ssh define dos

9. colas derivadas: ssh_login y ssh_bulk. A ssh_login se le ha dado una prioridad más alta que
a ssh_bulk, y ambas tienen ECN activado. A la cola de ftp se le ha asignado un ancho de
banda de 500Kbps y se le ha dado una prioridad de 3. También puede tomar prestado ancho
de banda cuando haya disponible ancho de banda adicional. Tiene RED activado.
Asignación de Tráfico a una Cola
Para asignar tráfico a una cola se usa la clave queue junto con las reglas de filtrado de PF.
Por ejemplo, en un conjunto de reglas de filtrado que contengan una línea como:
pass out on fxp0 from any to any port 22
Los paquetes que coincidan con esa regla pueden ser asignados a una cola específica
usando la clave queue:
pass out on fxp0 from any to any port 22 queue ssh
Cuando se usa la clave queue con directivas de bloqueo block, cualquier paquete TCP RST
o ICMP resultante que no se pueda alcanzar será asignado a la cola específica.
Nótese que la clasificación de la cola puede tener lugar en una interfaz que no sea la
definida por la directiva altq on:
altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
queue std cbq(default)
queue ftp bandwidth 1.5Mb
pass in on dc0 from any to any port 21 queue ftp
La formación de cola está activada en la interfaz fxp0, pero la clasificación tiene lugar en la
interfaz dc0. Si los paquetes que coinciden con la regla pass salen de la interfaz fxp0,
pasarán a la cola ftp. Este tipo de formación de colas puede ser muy útil para enrutadores.
Normalmente sólo se da un nombre de cola con la clave queue, pero si se especifica un
segundo nombre esa cola se usará para paquetes con un Tipo de Servicio (ToS, Type of
Service) de retraso bajo y para paquetes TCP ACK sin carga útil de datos. Un buen ejemplo
de esto se encuentra cuando se usa SSH. Las sesiones de ingreso de SSH configuran el ToS
para retrasos bajos, mientras que las sesiones de SCP y SFTP no. PF puede usar esta
información para poner en la cola paquetes que pertenezcan a una conexión de ingreso en
una cola diferente a la de las conexiones que no sean de ingreso. Esto es útil para dar

10. prioridad a los paquetes de conexiones de ingreso sobre los paquetes de transferencia de
archivos.
pass out on fxp0 from any to any port 22 queue(ssh_bulk, ssh_login)
Esto asigna los paquetes que pertenecen a las conexiones de ingreso de SSH a la cola
ssh_login, y los paquetes que pertenecen a las conexiones de transferencia de archivos de
SCP y SFTP a la cola ssh_bulk. En consecuencia, los paquetes de las conexiones de ingreso
de SSH serán procesados antes que los de las conexiones de SCP y SFTP, ya que la cola
ssh_login tiene una prioridad más alta.
La asignación de paquetes TCP ACK a una cola de prioridad más alta es útil en conexiones
asimétricas, o sea aquellas conexiones que tienen anchos de banda de carga y descarga
diferentes, como las líneas ADSL. Con una línea ADSL, si se está uilizando al máximo el
canal de carga y se inicia una descarga, la descarga sufrirá por que los paquetes TCP ACK
que necesita enviar entrarán en congestión cuando intenten pasar a través del canal de
carga. Las pruebas realizadas demuestran que para obtener los mejores resultados, el ancho
de banda en la cola de carga debe estar configurado con un valor inferior al de la capacidad
de la conexión. Por ejemplo, si una línea ADSL tiene un máximo de carga de 640Kbps, al
configurar el ancho de banda de la cola matriz, se obtendrán mejores resultados con un
valor de 600Kb. La forma para obtener la mejor configuración del ancho de banda es
probando varias configuraciones.
Cuando se usa la clave queue con reglas keep state, como:
pass in on fxp0 proto tcp from any to any port 22 flags S/SA
keep state queue ssh
PF registra la cola en la entrada de la tabla de estado, para que los paquetes que vuelvan
desde fxp0 y que coincidan con la conexión de mantenimiento de estado (stateful
connection) acaben en la cola ssh. Nótese que, aunque se esté usando la clave queue en una
regla que filtra el tráfico entrante, el objetivo es especificar una cola para el tráfico saliente
correspondiente; la regla anterior no pone en cola los paquetes entrantes.
Mediciones de la calidad de la voz (señales vocales)
Dos tipos de herramientas
No intrusivas: Sobre comunicaciones reales sin señales de referencia. Mejores para la
supervisión de la QoS de redes

11. Intrusivas de extremo a extremo: Con señales de prueba con señal de referencia, más
adaptadas para mediciones de la calidad percibida por ususarios finales
Las técnicas no intrusivas
La técnicas de mediciones no intrusivas:
Pueden implementarse como parte de los equipos de red (conmutadores) o en dispositivos
autónomos
Las herramientas utilizadas se conocen como INMD (Dispositivos de medidas no intrusivas
en servicio)
Se pueden medir dos tipos de parámetros:
Relacionados con el protocolo o la señalización
Números llamante y llamado, duración llamada, pérdida de paquetes, retardo ida y vuelta,
etc.
Derivados del análisis de las señales vocales:
Eco, ruido y niveles vocales tasa de pérdida de paquetes IP, recortes, etc.
Enlaces con la calidad percibida y programa de trabajo
El análisis de los resultados de mediciones puede gacerse para parámetros individuales o
combinando varios parámetros :Utilización de modelos de opinión de clientes:
Modelo E (G.107)
CCI (Índice de claridad de llamadas)
Se buscan modelos para evaluación de la calidad de transmisión de voz a partir de
información de análisis en redes IP (en curso)