QoS: qué ocurre realmente cuando un enlace se congestiona
Cando hablamos de rendimiento de red solemos fijarnos primero en el ancho de banda. “Tenemos un enlace de 1 Gbps.”, “Esta sede dispone de 100 Mbps., “Vamos a ampliar la conexión a Internet.”
Pero disponer de cierta capacidad no significa que todos los paquetes puedan atravesar el enlace inmediatamente. Cuando varios flujos intentan transmitir más información de la que una interfaz puede enviar, aparece la congestión.
Y ahí empieza QoS.
¿Qué significa QoS?
QoS significa Quality of Service. Es un conjunto de mecanismos utilizados para decidir cómo debe tratar una red distintos tipos de tráfico, especialmente cuando existe congestión.
La idea fundamental es sencilla:
Un enlace tiene una capacidad máxima. Si una interfaz puede transmitir 100 Mbps y recibe durante cierto período tráfico a 130 Mbps, no puede enviar esos 130 Mbps al mismo tiempo.
Tiene varias posibilidades:
• Guardar temporalmente paquetes en una cola;
• Transmitir primero unos paquetes y después otros;
• Limitar determinados flujos;
• Descartar paquetes cuando las colas se llenan.
QoS permite controlar ese comportamiento. Lo importante es entender qué no hace. QoS no convierte un enlace de 100 Mbps en uno de 200 Mbps. Solo permite gestionar mejor los 100 Mbps existentes.
Por qué QoS importa en el mundo real
No todas las aplicaciones reaccionan igual ante una red congestionada.
Una descarga de varios gigabytes puede tolerar pequeños retrasos. Si tarda 42 segundos en lugar de 40, probablemente nadie lo note.
Una llamada de voz es diferente. La voz en tiempo real necesita que los paquetes lleguen con una latencia relativamente estable. Si empiezan a acumularse en colas, el usuario puede experimentar cortes, retrasos o conversaciones poco naturales.
Algo parecido ocurre con otros flujos interactivos. Por eso no siempre tiene sentido tratar todos los paquetes exactamente igual. Imagina una oficina conectada a otra sede mediante un enlace WAN de 100 Mbps.
Por ese enlace circulan:
• Llamadas VoIP;
• Acceso a una aplicación corporativa;
• Sesiones de administración;
• Transferencias de archivos;
• Copias de seguridad.
Durante la mayor parte del día quizá el tráfico total sea de 30 Mbps. En ese momento QoS tendrá poco que decidir: hay capacidad de sobra. Pero a las 14:00 empieza una copia de seguridad y el tráfico intenta superar los 100 Mbps.
Ahora sí hay un problema.
Los paquetes empiezan a competir por una capacidad limitada.
Cómo funciona QoS paso a paso
Podemos entender una política QoS como varias etapas.
Paso 1: clasificar el tráfico
Primero necesitamos saber qué tipo de tráfico estamos viendo.
La clasificación puede basarse, dependiendo del entorno, en elementos como:
• Direcciones IP;
• Protocolos;
• Puertos;
• Interfaces;
• VLAN;
• Marcas DSCP;
• Otras propiedades conocidas por el dispositivo.
El resultado podría ser algo conceptual como:
Clase 1: voz
Clase 2: aplicaciones críticas
Clase 3: tráfico general
Clase 4: backups
Clasificar no significa todavía priorizar.
Simplemente estamos agrupando paquetes para poder tratarlos de manera diferente.
Paso 2: marcar
En algunas arquitecturas, después de clasificar se marca el tráfico. Uno de los mecanismos habituales en redes IP es DSCP.
La marca puede viajar dentro del encabezado IP y ayudar a otros dispositivos a reconocer el tratamiento deseado.
Pero hay una advertencia importante:
- Una marca no garantiza por sí sola ningún comportamiento.
- Un paquete puede llevar una determinada marca DSCP y atravesar un router que simplemente la ignore.
- QoS funciona porque los dispositivos tienen políticas que interpretan esas marcas.
Paso 3: colocar paquetes en colas
Supongamos que una interfaz puede transmitir a 100 Mbps.
Mientras llegan 50 Mbps, no existe un problema importante: los paquetes pueden salir aproximadamente al ritmo al que llegan.
Ahora empiezan a llegar 120 Mbps.
La interfaz no puede enviar todos inmediatamente.
Los paquetes pendientes se almacenan temporalmente en buffers.
Conceptualmente:
- Entrada: 120 Mbps
- [COLAS]
- Salida: 100 Mbps
Esos 20 Mbps adicionales tendrán que esperar o acabar siendo descartados si la situación continúa.
Recibe nuestra Newsletter de Cloud semanal
Paso 4: decidir quién sale primero
Aquí entra el scheduler.
Supongamos que tenemos tres colas:
- [VOZ]
- [APLICACIONES]
- [TRÁFICO GENERAL]
- Interfaz WAN
El dispositivo necesita decidir de qué cola toma el siguiente paquete. Podríamos configurar un tratamiento preferente para la voz y repartir el resto de la capacidad entre las demás clases. El objetivo no es hacer que todos reciban exactamente lo mismo.
El objetivo es que cada tipo de aplicación reciba un comportamiento adecuado.
Paso 5: controlar el ritmo
Otro concepto importante es el shaping. Shaping consiste en limitar deliberadamente el ritmo de salida del tráfico, almacenando paquetes temporalmente para producir un flujo más controlado.
Por ejemplo, nuestra interfaz física podría ser de 1 Gbps, pero el proveedor podría habernos contratado un servicio de 200 Mbps.
Podría tener sentido aplicar shaping aproximadamente a esa capacidad contratada para controlar nosotros mismos dónde se produce la cola.
Conceptualmente:
- Interfaz física: 1 Gbps
- Servicio contratado: 200 Mbps
- Shaper: ~200 Mbps
La idea es evitar enviar ráfagas a una velocidad que el siguiente dispositivo terminará descartando de forma menos controlada.
Ejemplo práctico
Tenemos una sede con un enlace WAN de 100 Mbps. Durante un momento concreto aparecen estos flujos:
- VoIP: 10 Mbps
- Aplicación corporativa: 25 Mbps
- Navegación: 20 Mbps
- Backup: 70 Mbps
- Total: 125 Mbps
Queremos transportar 125 Mbps por un enlace capaz de transmitir 100 Mbps. Es físicamente imposible hacerlo simultáneamente.
Tenemos un exceso de 25 Mbps.
Sin una política específica, los diferentes flujos competirán por las colas disponibles según el comportamiento del dispositivo.
Ahora imaginemos una política conceptual:
VOZ
Prioridad para tráfico sensible a latencia.
APLICACIONES
Ancho de banda garantizado durante congestión.
GENERAL
Servicio normal.
BACKUP
Utiliza capacidad disponible sin perjudicar a las clases anteriores.
Mientras el enlace utiliza solo 40 Mbps, probablemente todas las clases puedan transmitir sin restricciones apreciables. Cuando llegamos a 100 Mbps, empiezan a importar las decisiones del scheduler.
El backup puede ralentizarse mientras se protege el tráfico interactivo.
Esto es una distinción importante:
– QoS no pretende necesariamente impedir que el backup utilice mucho ancho de banda.
– Puede permitírselo cuando existe capacidad libre.
Lo que queremos evitar es que una transferencia no sensible a latencia perjudique a una aplicación que sí lo es cuando aparece congestión.
Errores típicos y cómo evitarlos
Antes de aplicar QoS, conviene conocer los errores más habituales que pueden hacer que una política no consiga el resultado esperado. Algunos problemas están relacionados con la configuración, mientras que otros surgen de no identificar correctamente dónde y cuándo aparece la congestión.
1. Pensar que QoS genera ancho de banda
No lo hace. Si necesitas transportar continuamente 500 Mbps y tienes un enlace de 100 Mbps, ninguna política QoS solucionará el problema fundamental. Probablemente necesitas más capacidad. QoS sirve para decidir cómo gestionar una capacidad limitada.
2. Configurar QoS donde no está la congestión
Puedes crear una política perfecta en una interfaz que nunca se llena. No cambiará prácticamente nada. La primera pregunta debería ser: ¿Dónde se forma realmente la cola? Ese punto puede estar en tu router, pero también puede encontrarse en otro dispositivo o dentro de la infraestructura del proveedor.
3. Dar prioridad absoluta a demasiado tráfico
Si marcas prácticamente todo como prioritario, has dejado de priorizar. Las clases preferentes deben reservarse para el tráfico que realmente lo necesita. Una red en la que el 80 % del tráfico es “crítico” probablemente tiene un problema de clasificación.
4. Confundir shaping y policing
Aunque ambos controlan tráfico, no funcionan igual. De forma simplificada:
- Shaping intenta suavizar el ritmo, reteniendo paquetes temporalmente.
- Policing controla si el tráfico supera una determinada política y puede terminar descartando o remarcando tráfico excedente.
Uno utiliza colas para retrasar tráfico. El otro puede actuar directamente sobre aquello que excede el límite definido.
5. Ignorar el tamaño de las colas
Una cola enorme evita descartes durante más tiempo, pero puede introducir mucha latencia. Imagina que los paquetes pueden permanecer cientos de milisegundos esperando antes de transmitirse.
El enlace aparentemente “funciona”, porque no pierde paquetes, pero una aplicación interactiva puede funcionar fatal. Más buffer no significa automáticamente mejor rendimiento.
Checklist rápido: si mañana lo aplicas…
Antes de desplegar una política QoS, comprueba:
• ¿Existe realmente congestión?
• ¿En qué interfaz exacta ocurre?
• ¿Cuál es la capacidad real disponible?
• ¿Qué aplicaciones son sensibles a latencia?
• ¿Cuáles necesitan throughput pero pueden esperar?
• ¿Cómo estás clasificando el tráfico?
• ¿Confías en las marcas recibidas o las defines tú?
• ¿Qué ocurre cuando una cola alcanza su límite?
• ¿Necesitas shaping antes de entregar tráfico al proveedor?
• ¿Puedes medir drops, utilización y longitud de colas?
• ¿Has probado la política bajo congestión real?
Y, sobre todo, compara antes y después.
QoS sin observabilidad puede convertirse rápidamente en una colección de reglas difíciles de justificar.
La idea que conviene recordar
QoS se entiende mucho mejor cuando dejamos de pensar en “dar prioridad” y pensamos en gestionar una cola. Si no existe congestión, los paquetes simplemente salen.
Cuando llegan más paquetes de los que el enlace puede transmitir, alguien tiene que decidir:
qué espera,
cuánto espera,
qué sale primero,
y qué acaba descartándose.
Eso es lo que realmente estamos controlando con QoS. Por eso una buena política no empieza escribiendo comandos. Empieza identificando el cuello de botella y entendiendo qué aplicaciones sufren cuando aparece.
