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

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)

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)

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.

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

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:

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,

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

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

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

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)