El reclamo llegó un lunes: «la telefonía se corta justo cuando alguien sube respaldos». El gráfico del enlace mostraba un plácido 40 % de uso promedio, y el gerente preguntaba — con toda razón — para qué había pagado 100 Mbps. La trampa: el promedio se mide en minutos y la congestión ocurre en milisegundos. Basta una ráfaga de 30 ms que llene la cola de salida para que un paquete de voz llegue tarde a su cita. Ahí entra QoS, y conviene decirlo de entrada: QoS no le agrega ni un bit al enlace. Es triaje.
QoS no fabrica ancho de banda
Piensa en la sala de urgencias de un hospital. El triaje no construye pabellones ni contrata médicos: decide quién pasa primero cuando no alcanza para todos. QoS es exactamente eso para una interfaz de red: cuando llegan más paquetes de los que caben en el cable, alguien tiene que esperar en la cola — o descartarse — y QoS elige a quién le duele. Nada más, y nada menos.
De ahí salen dos verdades incómodas. Uno: sin congestión, QoS no hace nada. Con la cola vacía, el paquete marcado como oro y el marcado como carbón salen igual de rápido; toda tu política elegante es un adorno. Dos: si el enlace vive congestionado, QoS es anestesia, no cura — la voz sonará impecable mientras todo lo demás agoniza, y la solución de fondo es más ancho de banda. El terreno fértil de QoS es el medio: enlaces que en promedio sobran pero sufren microrráfagas, que es exactamente donde vive el 90 % de las redes reales.
DSCP: el sticker en la frente del paquete
Para discriminar con criterio primero hay que etiquetar. En el encabezado IPv4 hay un byte que nació llamándose «Type of Service» y hoy es el campo DiffServ: sus 6 bits superiores son el DSCP (Differentiated Services Code Point) y los 2 restantes son ECN, que es otra película. Seis bits dan 64 valores posibles, pero en la práctica cuatro hacen casi todo el trabajo:
| Clase | DSCP | Binario | Byte ToS | Úsalo para |
|---|---|---|---|---|
| EF | 46 | 101110 | 0xB8 | voz RTP: poca, sagrada, sensible al retardo |
| AF41 | 34 | 100010 | 0x88 | video interactivo (videollamadas, telepresencia) |
| CS0 | 0 | 000000 | 0x00 | mejor esfuerzo: web, correo, casi todo |
| CS1 | 8 | 001000 | 0x20 | scavenger: respaldos, actualizaciones, lo sacrificable |
EF (Expedited Forwarding) es para tráfico que prefiere morir antes que llegar tarde: la voz. AF41 le da al video interactivo garantía de ancho de banda sin el pase VIP de la voz. CS0 es el ciudadano común. Y CS1 — la clase scavenger — es la más subvalorada del catálogo: marca ahí los respaldos y las actualizaciones y podrán usar todo el enlace a las 3 de la mañana, pero cederán hasta el último bit cuando alguien lo necesite. A veces la mejor QoS no es subir a la voz: es bajar al respaldo.
Para ver la marca en vivo basta un tcpdump: el byte ToS aparece en cada paquete.
$ sudo tcpdump -n -v -c1 udp portrange 16384-32767
IP (tos 0xb8, ttl 63, id 4211, offset 0, proto UDP (17), length 200)
10.1.20.14.16402 > 10.1.9.7.16388: UDP, length 172 Ese tos 0xb8 es el mismo EF escrito de otra forma: 46 corrido dos bits a la izquierda (46 × 4 = 184 = 0xB8). Las conversiones entre DSCP, ToS, binario y nombres de clase — con las 21 clases estándar — las tienes en la calculadora DSCP / QoS.
La frontera: confiar o remarcar
Un sticker lo pega cualquiera. Si tu política dice «EF pasa primero», nada impide que un PC con el driver de red «optimizado para gaming» marque sus paquetes como EF y se cuele en la fila de la voz. Por eso toda red seria define una frontera de confianza: en el puerto de acceso decides si le crees a las marcas que llegan o las reescribes. ¿Teléfono IP corporativo? Se le cree. ¿Laptop de usuario? Gracias por participar: todo a CS0, y si es tráfico conocido de voz o video, lo remarcas tú con una ACL. Del borde hacia el núcleo ya nadie clasifica de nuevo: se confía en la marca y punto — clasificar por DPI en el core es caro; confiar mal, carísimo.
Y aquí la parte que suele olvidarse: la marca por sí sola es decoración. El trabajo sucio lo hacen las colas. Un switch o router serio clasifica cada paquete por su DSCP hacia una cola distinta: EF a la cola prioritaria (se atiende antes que todas, con un policer encima para que la voz jamás se coma el enlace entero), AF41 a una cola con ancho de banda garantizado, CS0 a la cola común y CS1 a las migas. La marca es el diagnóstico; la cola es el tratamiento.
El balde de fichas: así se mide «cuánto puede pasar»
Marcar y encolar ordenan la fila; falta el guardia que mide el caudal. Casi todos los equipos usan el mismo mecanismo: el token bucket, el balde de fichas. Funciona como los juegos de un arcade: transmitir 1 bit cuesta 1 ficha. Las fichas caen al balde a ritmo constante — el CIR, tu tasa comprometida — y el balde tiene un tamaño máximo, Bc. Si el balde está lleno, las fichas nuevas se derraman y se pierden: no existe el ahorro infinito. ¿Llega un paquete y hay fichas? Pasa de inmediato. ¿No hay? Ahí se define el carácter del guardia, y lo vemos en un momento.
Con números redondos y verificados: CIR de 1 Mbps y Bc de 8.000 bits. El intervalo de recarga es Tc = Bc ÷ CIR = 8.000 ÷ 1.000.000 = 8 ms, o sea 125 recargas por segundo de 8.000 bits cada una — que multiplicadas dan exactamente el CIR. Y como el balde nunca guarda más de Bc, la ráfaga máxima instantánea es Bc: 8.000 bits, unos 1.000 bytes de una sola vez.
El balde es lo que hace tolerable la vida real: el tráfico nunca es plano, y Bc define cuánta ráfaga perdonas sin castigar el promedio. Ahora sí, ¿qué pasa cuando llega tráfico y no quedan fichas? Dos filosofías:
- Policing — la tijera. El exceso se descarta o se remarca a una clase peor, en el acto. Sin cola, sin retardo extra, sin memoria. Brutal pero barato.
- Shaping — el embudo. El exceso se encola y espera fichas. Nada se pierde (mientras la cola aguante), pero el precio es retardo: la ráfaga sale «planchada» al ritmo del CIR.
Misma ráfaga, destinos distintos: llegan 20.000 bits de golpe con el balde lleno. El policer deja pasar 8.000 (las fichas que había) y corta 12.000. El shaper deja pasar los mismos 8.000 de inmediato y encola los otros 12.000, que salen en los 12 ms siguientes (12.000 ÷ 1.000.000). Todo llega — más tarde.
¿Cuándo cada uno? Police lo que recibes: en el borde de entrada, para que ningún cliente o sede se pase de lo contratado. Shape lo que envías hacia un enlace más lento o hacia un CIR contratado: prefieres que tu propia cola decida qué espera, con tus prioridades, antes que el policer del otro lado corte parejo y sin criterio. TCP, además, sufre mucho menos con retardo que con pérdidas: cada drop del policer es una retransmisión y un frenazo de ventana. Los parámetros — CIR, Bc, Tc y si tu ráfaga pasa o no — los puedes probar en la calculadora de token bucket.
Jitter buffer: comprar orden con latencia
Aunque marques y suavices perfecto, la red nunca entrega con ritmo de reloj. La voz lo necesita: un códec con ptime de 20 ms emite un paquete cada 20 ms exactos — 50 por segundo — y el que escucha necesita reproducirlos con ese mismo compás. La variación entre llegadas es el jitter, y el remedio es el jitter buffer: una sala de espera que retiene los paquetes recién llegados unos instantes y se los entrega al códec con metrónomo. El truco es que ese orden se compra con latencia — cada milisegundo de buffer es un milisegundo más de retardo en la conversación. La regla práctica de dimensionamiento: 2 × el jitter medido. Hagamos la cuenta completa:
- Mides el jitter real de la red hacia la central: 20 ms. La llamada usa ptime de 20 ms (un paquete de voz cada 20 ms).
- Buffer = 2 × jitter = 2 × 20 = 40 ms. En profundidad: 40 ÷ 20 = 2 paquetes esperando en la sala.
- Presupuesto boca-a-oído: red 50 ms + buffer 40 ms + códec 15 ms + paquetización (ptime) 20 ms = 125 ms.
- La recomendación ITU-T G.114 pone el límite cómodo en 150 ms en un sentido: 125 ≤ 150 → conversación fluida, con 25 ms de holgura.
- Contraprueba: si el jitter sube a 40 ms, el buffer se va a 80 ms y el total a 165 ms — sobre el límite, y aparece el efecto walkie-talkie donde ambos hablan encima del otro. El jitter cobra doble: desordena la llegada y encarece el buffer.
Ese es el motivo de fondo para marcar la voz EF y darle cola prioritaria: no es por los megabits (una llamada pesa poco), es por mantener el jitter a raya para que el buffer pueda ser pequeño. Dimensiona el buffer y el presupuesto boca-a-oído con la calculadora de jitter buffer, y el ancho de banda real por llamada — con todos sus encabezados — con la calculadora VoIP.
Video: reserva por percentil, no por promedio
El video es el elefante de la sala de QoS: una sola cámara puede pesar más que toda tu telefonía junta. Su bitrate depende de resolución, cuadros por segundo, códec y calidad (bits por píxel), y la palanca grande es el códec: a calidad comparable, H.265 pide más o menos la mitad que H.264. Un 1080p30 a 0,1 bpp da 1920 × 1080 × 30 × 0,1 ≈ 6,2 Mbps en H.264 y ≈ 3,1 Mbps en H.265. Estima el tuyo — con tus resoluciones y calidades — en la calculadora de bitrate de video.
El detalle que rompe redes: ese número es un promedio, y el video moderno es de tasa variable. Escena quieta, casi nada; alguien camina frente a la cámara o llega un I-frame, y el bitrate salta a 2 o 3 veces el promedio durante unos cientos de milisegundos. Si dimensionaste la cola AF41 con el promedio, cada pico llega justo cuando la garantía no alcanza — y el video pixela exactamente en el momento interesante. Reserva por percentil (el p95 del bitrate real medido, no el folleto), y deja que el shaping absorba lo que asome por encima.
La receta corta
QoS en serio son cuatro movimientos: comprueba que la congestión existe (en milisegundos, no en promedios de 5 minutos), marca en el borde y remarca lo que no controlas, dale a cada clase una cola con garantía real, y suaviza tus salidas antes de que el policer de otro las corte. Empieza hoy: revisa con tcpdump si tu voz llega marcada EF a la salida — es un minuto, y la respuesta suele ser la mitad del diagnóstico.