Qué es QoS Packet Scheduler de Windows y cómo aprovecharlo

Si alguna vez has buceado por las opciones avanzadas de red de Windows, seguro que te has topado con algo llamado QoS Packet Scheduler y con el típico mito del “Windows se guarda el 20% del ancho de banda”. Este tema genera bastante confusión, sobre todo porque se mezcla con consejos de “optimización para juegos” que poco tienen que ver con cómo funciona realmente la calidad de servicio en el sistema operativo.

En las empresas, y cada vez más en casa con VoIP, videollamadas y teletrabajo, entender qué es el programador de paquetes QoS de Windows, cómo se relaciona con las políticas de QoS, con Hyper-V, DCB, el marcado DSCP y la limitación de tráfico es clave para priorizar el tráfico importante sin desperdiciar ancho de banda. Vamos a verlo con calma, pero con un lenguaje aterrizado a la vida real.

Qué es QoS y qué papel juega el Packet Scheduler en Windows

La calidad de servicio (QoS) es el conjunto de mecanismos de red que permiten controlar cómo se trata el tráfico, de modo que las aplicaciones críticas (VoIP, videoconferencias, IPTV, VOD, juegos online, flujos en tiempo real, etc.) tengan el rendimiento que necesitan incluso cuando la red está saturada.

En una red con QoS bien diseñada, no todo el tráfico se trata igual: se priorizan ciertos flujos, se reserva ancho de banda mínimo, se aplican límites máximos y se decide qué paquetes se pueden descartar antes si hay congestión. Para eso se analizan parámetros como ancho de banda disponible, latencia, jitter y pérdida de paquetes, y se ajusta la forma en la que los routers, switches y equipos finales encolan y envían los paquetes.

Dentro de Windows, el componente clave que materializa esta lógica es el QoS Packet Scheduler, el programador de paquetes. Es el módulo de control de tráfico encargado de decidir cuánto tráfico puede enviar cada flujo o aplicación y en qué orden, en función de las políticas de QoS definidas (por ejemplo, a través de GPO) y de la clasificación que se haya hecho de los paquetes.

Este programador se apoya en un clasificador genérico de paquetes (Generic Packet Classifier, GPC), en un conformador, un packet shaper y un secuenciador. El clasificador etiqueta el tráfico según reglas (aplicación, puertos, direcciones IP, protocolo, etc.), y el programador utiliza esa información para aplicar prioridades y mecanismos como la conformación y el reordenamiento de paquetes.

El componente de packet shaping, integrado dentro del QoS Packet Scheduler, suaviza los picos de transmisión típicos de las aplicaciones IP (que tienden a “soltarlo todo de golpe”). En lugar de mandar ráfagas enormes que puedan congestionar la red, reparte esos envíos en el tiempo, logrando un uso más estable y eficiente del enlace.

Desmontando el mito del 20% de ancho de banda reservado en Windows

Uno de los malentendidos más extendidos es la idea de que Windows, por culpa de QoS Packet Scheduler, “reserva” un 20% del ancho de banda y no lo deja usar nunca. Este mito ha alimentado montones de tutoriales que recomiendan deshabilitar el programador de paquetes o poner a cero un supuesto “ancho de banda reservado” para que “internet vaya más rápido”.

En realidad, el programador de paquetes QoS de Windows se dedica a priorizar tráfico, no a dejar ancho de banda muerto. Si en un momento dado no hay tráfico que deba ser tratado con una prioridad concreta o que tenga ancho de banda mínimo garantizado, ese ancho de banda simplemente lo aprovechan otros flujos, no se desperdicia.

Desde el punto de vista de QoS, cuando quieres garantizar recursos para cierto tráfico, debes decidir si vas a hacerlo priorizando esos flujos o limitando el resto. Son enfoques diferentes: uno da trato preferente, el otro frena a los demás. El programador de paquetes de Windows está orientado al primer enfoque: prioriza y da garantías, no capado permanente al enlace.

Si lo que quieres es imponer límites estrictos de velocidad a determinados procesos o sockets, necesitas herramientas específicas de limitación de tráfico, no tocar el Packet Scheduler. Existen utilidades como NetLimiter que permiten controlar el ancho de banda consumido por procesos concretos, conexiones o incluso puertos, algo muy útil para escenarios de pruebas o diagnósticos.

Por otro lado, hay programas como WinTC que se apoyan en el Programador de Paquetes QoS para crear reglas y exprimir estas capacidades avanzadas de priorización. No son especialmente amigables (suelen funcionar con ficheros .conf), pero demuestran que el Packet Scheduler es una herramienta potente para controlar la calidad de servicio, no un freno artificial.

QoS en Windows: políticas, DSCP y limitación de tráfico

En los sistemas operativos Windows modernos, la QoS a nivel de host se gestiona principalmente mediante políticas de QoS integradas con Directiva de grupo. Esto permite que un administrador defina reglas centralizadas que se aplican a usuarios y equipos desde Active Directory.

Estas políticas combinan dos controles fundamentales: el valor DSCP (para priorización en la red) y la velocidad de limitación (para limitar el tráfico saliente). El objetivo es garantizar que el tráfico sensible (por ejemplo, VoIP corporativa o una aplicación de negocio crítica) tenga la prioridad adecuada y no se vea sepultado por transferencias masivas o tráfico de menor importancia.

El valor DSCP (Differentiated Services Code Point), definido en la RFC 2474, ocupa 6 bits dentro del campo TOS en IPv4 (o Clase de tráfico en IPv6) y permite marcar cada paquete con un nivel de servicio de 0 a 63. Los routers utilizan este valor para clasificar y encolar los paquetes, situando los más prioritarios en colas con mejor tratamiento (menor latencia, menos pérdida, etc.).

La segunda pata es la limitación, que se configura mediante una velocidad de throttling para el tráfico saliente al que se aplique la política. Con esta opción, el Packet Scheduler hace que ciertos flujos no superen una tasa de salida determinada (en KB/s o MB/s). Esto es muy útil para que una sola aplicación de copia de datos o backup no se coma todo el ancho de banda de la oficina.

Uso del Asistente para directivas QoS en Windows

Windows incluye un Asistente para directivas QoS que simplifica mucho la creación, edición y eliminación de estas reglas. Se accede a él desde la Consola de administración de directivas de grupo (GPMC) al editar un GPO, tanto en la rama de configuración de equipo como en la de usuario.

Las políticas QoS definidas en Configuración del equipo → Configuración de Windows → Directiva QoS se aplican a las máquinas, con independencia del usuario que inicie sesión. Suelen utilizarse para servidores o para escenarios en los que el comportamiento de la red debe ser consistente en el equipo.

Las que se encuentran en Configuración de usuario → Configuración de Windows → Directiva QoS se aplican a los usuarios, también independientemente del equipo en el que entren. Esto encaja bien con entornos de usuarios móviles o con distintas estaciones de trabajo.

A la hora de crear una nueva política con el asistente, el primer paso es la página de Perfil de directiva. Aquí se asigna un nombre único y se define si la regla marcará DSCP, limitará el tráfico o ambas cosas a la vez. El valor DSCP puede ir de 0 a 63, y la velocidad de limitación se fija en unidades de KB/s o MB/s, con un valor superior a 1.

En la segunda página, llamada Nombre de la aplicación, decides si la política se aplicará a todas las aplicaciones o solo a una en concreto. Puedes indicar el nombre del ejecutable terminando en .exe, e incluso la ruta completa (incluyendo variables de entorno como %ProgramFiles%). También existe la opción de vincularla a aplicaciones de servidor HTTP que atienden a una URL específica, siguiendo el formato de RFC 1738 (como http[s]://host:puerto/ruta), con soporte de comodines para hostname y puerto.

La tercera página del asistente está dedicada a las direcciones IP de origen y destino. Es posible usar “cualquier dirección IP” o filtrar por una dirección concreta IPv4/IPv6 o por un prefijo en notación CIDR, como 192.168.1.0/24 o 3ffe:ffff::/48. Si se especifica una dirección URL en la página anterior, la IP de origen quedará bloqueada porque corresponde al servidor HTTP y no se puede modificar desde ahí.

La cuarta y última página se centra en protocolos y puertos. Puedes limitar la política a tráfico TCP, UDP o a ambos, y elegir entre todos los puertos o un número/intervalo concreto, tanto para origen como para destino. Los rangos se expresan con el formato Bajo:Alto (por ejemplo, 10000:20000), sin espacios, y los valores deben estar entre 1 y 65535.

Al terminar el asistente, la nueva política aparece listada en el Editor de objetos de directiva de grupo. Para que surta efecto, hay que vincular el GPO a un dominio, sitio o unidad organizativa de Active Directory.

Visualización, edición y auditoría de políticas QoS

Una vez desplegadas varias directivas QoS en una organización, conviene revisar de vez en cuando cómo se están aplicando. Desde el propio Editor de objetos de directiva de grupo se pueden ver y editar las propiedades de cada política: perfil, aplicación, direcciones IP, protocolos y puertos.

Para obtener una visión consolidada por usuario o equipo, GPMC ofrece el Asistente para resultados de directiva de grupo. Al generar un informe, en la pestaña Configuración aparecen las políticas QoS activas tanto en Configuración del equipo como en Configuración de usuario, con su nombre, valor DSCP, velocidad de limitación, condiciones y el GPO que prevalece.

Cuando varias GPO contienen políticas con el mismo nombre, se aplica solo la directiva procedente del GPO con mayor prioridad. Las demás quedan descartadas en caso de conflicto. Es importante entender que, a partir de ahí, en el nivel de host o usuario, son las propias reglas de prioridad interna de QoS las que deciden qué política se impone para cada flujo concreto.

Reglas de prioridad entre directivas QoS

Las directivas QoS no se suman entre sí ni se aplican en cascada para un mismo flujo: para cada tráfico de salida TCP o UDP, solo puede estar activa una política a la vez. Por eso, cuando se solapan varias, hay un conjunto de reglas de prioridad que determina cuál es la que manda.

En primer lugar, las políticas de nivel de usuario tienen prioridad sobre las de nivel de equipo. Esto simplifica la vida de los administradores cuando diseñan GPO basadas en grupos de usuarios, ya que no necesitan preocuparse tanto por posibles conflictos con políticas de máquina: si un usuario tiene una política que encaja en un tráfico, y el equipo tiene otra contradictoria, prevalece la de usuario.

En segundo lugar, se mide la especificidad de la política. Las que se refieren a una aplicación concreta (por nombre de .exe o por ruta) tienen prioridad sobre las que se definen solo por el quíntuple de red (IP origen, IP destino, puerto origen, puerto destino, protocolo). Dentro de las de aplicación, una política que incluye la ruta de la aplicación es considerada más específica que otra que solo dice “app.exe”.

Si incluso así varias políticas siguen coincidiendo con el mismo tráfico, se mira el quíntuple de red. La regla general es que la directiva con las condiciones más detalladas sobre ese quíntuple gana. Por ejemplo, una regla que especifique IP de destino 10.0.0.1 y puerto de destino 80 es más específica que otra que solo menciona IP 10.0.0.1 con cualquier puerto.

Cuando varias directivas tienen el mismo número de condiciones dentro del quíntuple, se recurre a un orden de prioridad interno: primero se valora la dirección IP de origen, luego la IP de destino, después el puerto de origen, el puerto de destino y, por último, el protocolo (TCP o UDP). En cada campo, un valor más concreto (por ejemplo, 192.168.4.1) tiene más peso que un prefijo amplio (192.168.4.0/24).

Esta lógica hace recomendable diseñar las políticas QoS con la mayor precisión posible, de manera que al leerlas resulte evidente qué tráfico se verá afectado y se minimicen sorpresas por conflictos inesperados.

QoS, usuarios itinerantes y conexiones remotas

Las políticas de QoS en Windows están pensadas para gestionar el tráfico dentro de la red corporativa. En entornos móviles, donde un portátil puede conectarse tanto desde la oficina como desde una red pública, es importante que QoS solo actúe cuando tiene sentido.

Por eso, en Windows 8, Windows 7 y Windows Vista, las directivas QoS solo se habilitan en interfaces de red que se consideren conectadas a la empresa. Por ejemplo, en un escenario en el que el usuario se conecta a la red corporativa a través de una VPN desde una cafetería, la interfaz física Wi-Fi no tendrá QoS activo, pero la interfaz virtual de la VPN sí aplicará las políticas.

Si ese mismo portátil se conecta posteriormente a la red de otra empresa con la que no existe relación de confianza en AD DS, las directivas QoS no se activarán. El enfoque está claramente orientado a que la calidad de servicio solo influya en los caminos de tráfico que forman parte de la infraestructura corporativa.

En cambio, en el mundo servidor (Windows Server 2012 y posteriores), las políticas QoS están habilitadas en todas las interfaces de red. Esto permite, por ejemplo, limitar o priorizar tráfico saliente hacia Internet desde servidores situados en el perímetro de la red, aunque esas interfaces no estén “dentro” de la LAN interna tradicional.

Configuración avanzada de QoS: recepción TCP y DSCP

Además de las políticas estándar, Windows ofrece una sección de Configuración avanzada de QoS accesible desde Configuración del equipo → Configuración de Windows → Directiva de QoS. Está pensada para ajustar el comportamiento global de la pila de red en el equipo.

La pestaña de Tráfico TCP entrante permite controlar el consumo de ancho de banda en el lado receptor regulando la ventana de recepción TCP que el sistema anuncia. Aunque por defecto Windows Server 2012, Windows 8 y versiones equivalentes establecen el nivel máximo de rendimiento, se puede reducir para limitar el volumen de datos que un servidor puede aceptar de golpe en conexiones con alto producto ancho de banda × retardo.

La ventana de recepción en versiones modernas de Windows puede crecer dinámicamente hasta unos 16 MB, muy por encima de los 64 KB que imponían versiones antiguas. En la configuración avanzada se ofrecen varios niveles (0, 1, 2, 3) que corresponden a 64 KB, 256 KB, 1 MB y 16 MB de máximo respectivamente. El valor real en cada momento dependerá de las condiciones de la red.

Otra pestaña importante es la de Invalidación de marcado de DSCP. Aquí se define si las aplicaciones que utilizan APIs de QoS pueden establecer por su cuenta valores DSCP distintos de los fijados por las políticas. Cuando se configura para “ignorar”, las solicitudes de marcado que hagan las aplicaciones se pisan y el valor DSCP pasa a cero, quedando el control en manos exclusivas de las políticas de QoS.

Por defecto, en Windows Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1 y otras versiones recientes, se permite que las aplicaciones definan sus propios valores DSCP, mientras que el tráfico que no utiliza APIs de QoS no se ve afectado por esta invalidación.

QoS, Wi-Fi y valores DSCP para tráfico multimedia

En redes inalámbricas modernas, la Wi-Fi Alliance define una certificación de Wireless Multimedia (WMM) que clasifica el tráfico en cuatro categorías de acceso: voz (VO), vídeo (VI), mejor esfuerzo (BE) y fondo (BK). Cada categoría se asocia a rangos de valores DSCP concretos.

Los rangos típicos se organizan de la siguiente forma: valores DSCP de 48 a 63 se consideran voz, de 32 a 47 corresponden a vídeo, de 24 a 31 y 0 a 7 representan mejor esfuerzo, y de 8 a 23 se asignan a tráfico de fondo. Al mapear tus políticas QoS a estos rangos, logras que los portátiles y otros dispositivos con adaptadores Wi-Fi certificados WMM reciban la prioridad adecuada cuando se conectan a puntos de acceso también certificados.

En la práctica, esto permite que llamadas VoIP, videoconferencias o streaming crítico de negocio se coloquen automáticamente en las colas inalámbricas que ofrecen menor latencia y menor probabilidad de pérdida, mejorando la experiencia del usuario en entornos Wi-Fi, que de por sí son más sensibles a interferencias y variaciones.

QoS en Hyper-V: ancho de banda mínimo, modos y mejores prácticas

En servidores que ejecutan Hyper-V, Windows incorpora un mecanismo de ancho de banda mínimo QoS a nivel de conmutador virtual, aplicado precisamente por el QoS Packet Scheduler. Su finalidad es garantizar que cada carga de trabajo virtual tenga una parte justa del enlace físico cuando hay congestión.

Al crear un conmutador virtual con PowerShell, se puede elegir el modo de configuración de ancho de banda mínimo mediante el parámetro -MinimumBandwidthMode de New-VMSwitch. Hay dos opciones: Weight (peso) y Absolute (bits por segundo, BPS). Esto cambia la forma de expresar la reserva mínima.

En modo peso, cada adaptador de red virtual recibe un entero (por ejemplo, entre 1 y 100) que indica su peso relativo. El programador de paquetes reparte el ancho de banda disponible en función de estos pesos, de forma proporcional. Si no hay congestión, todos pueden usar más, pero cuando la hay, el reparto se ajusta a esas proporciones.

En modo absoluto (BPS), se fija un mínimo en términos de tasa concreta, como 500 Mbps. En este caso, el sistema tiene que ser capaz de garantizar ese ancho de banda mínimo. Esto puede generar conflictos, por ejemplo, al hacer una migración en vivo a un host que no pueda asegurar ese mínimo. Un switch virtual configurado con MinimumBandwidthMode=Weight evita muchos de esos problemas al trabajar con proporciones en vez de números fijos.

Si se decide usar el modo absoluto, hay que tener en cuenta que la unidad mínima es el 1% de la capacidad del enlace. En una NIC de 10 GbE, eso significa que, por adaptador virtual, el mínimo efectivo más pequeño son 100 Mbps. Los valores se redondean al porcentaje más cercano, de modo que, por ejemplo, 234 Mbps acabarán siendo 200 Mbps (un 2% de 10 GbE).

Estrategias de asignación de pesos y consideraciones prácticas

Cuando se utiliza el modo de pesos en Hyper-V, conviene seguir una serie de recomendaciones para que el reparto de ancho de banda sea estable y tenga sentido. La primera es mantener la suma de pesos cerca de 100 o por debajo. Cuanto más grandes sean los valores de peso, mayor será el error de redondeo cuando el Packet Scheduler cree las particiones de ancho de banda.

Por ejemplo, si tienes 20 máquinas virtuales y quieres que compartan el ancho de banda de forma igualitaria, es preferible asignar peso 1 a cada una (suma 20) en lugar de darles peso 10 (suma 200). El reparto relativo será el mismo, pero con menos riesgo de errores de cuantificación al aplicar las proporciones.

Otra buena práctica es asignar un peso relativamente alto a cargas de trabajo críticas, incluso si su consumo real de ancho de banda es pequeño. Por ejemplo, el tráfico de administración y los latidos de clúster en un host Hyper-V con NIC de 10 GbE rara vez superan el 1-2% de uso, pero son vitales para la estabilidad del entorno. Darles peso 5 en lugar de 1 o 2 ayuda a garantizar que no se vean penalizados en situaciones de estrés.

También se aconseja usar pesos que permitan diferenciar claramente los niveles de servicio. En lugar de usar valores consecutivos (1, 2, 3) para máquinas Gold, Silver y Bronze, resulta más práctico emplear, por ejemplo, 5, 3 y 1. Así se amplifica la diferencia efectiva entre clases de servicio.

Por último, al definir filtros de QoS específicos para ciertos tipos de tráfico (como almacenamiento, migración en vivo, clúster, etc.), conviene tener presente el tráfico genérico no filtrado. Una práctica habitual es agruparlo con un filtro comodín y asignarle un peso concreto, de forma que todo lo no categorizado también tenga asignación clara dentro del reparto.

QoS, DCB y formación de equipos NIC

En entornos de centro de datos, además de QoS a nivel de host, es frecuente utilizar Data Center Bridging (DCB), un conjunto de extensiones Ethernet que se apoyan en el hardware de la NIC para ofrecer control de flujo basado en prioridad y garantías de ancho de banda en la propia red física.

El ancho de banda mínimo de QoS aplicado por el Packet Scheduler y el que ofrece DCB a través de la NIC tienen objetivos parecidos: asegurar que cada tipo de tráfico reciba su cuota justa bajo congestión. Sin embargo, no están diseñados para actuar simultáneamente sobre la misma pila de red o la misma NIC. Pueden convivir en un mismo servidor, pero deben aplicarse a pilas o adaptadores distintos.

La formación de equipos de NIC (NIC Teaming) añade otra capa a la ecuación. El teaming proporciona agregación de ancho de banda entre varios adaptadores y conmutación por error si alguno falla. Los algoritmos de distribución de tráfico pueden basarse en el puerto de conmutador virtual de Hyper-V o en hash de direcciones (MAC, IP, puerto de transporte).

Ciertas funcionalidades de QoS se integran sin problemas con el teaming. Por ejemplo, la clasificación y etiquetado funciona bien porque el marcado se realiza antes del hash. El control de flujo basado en prioridad (PFC) también es compatible, siempre que se habilite de forma coherente en todos los miembros del equipo. El ancho de banda máximo es otro caso sencillo: el Packet Scheduler limita los flujos antes de que el tráfico se distribuya entre las NIC.

La cosa se complica con el ancho de banda mínimo en modo peso. Como el programador reparte el ancho de banda entre flujos según peso antes del hashing, si el algoritmo de teaming se basa en el puerto de conmutador de Hyper-V, cada VM (una vNIC) constituye un único flujo. Es posible que el hash asigne varias máquinas muy “pesadas” a un miembro del equipo y varias ligeras a otro, dando como resultado un reparto efectivo más igualitario que proporcional.

Este efecto se atenúa si hay muchas máquinas virtuales compartiendo el conmutador virtual o si el algoritmo de teaming está basado en hash de direcciones, pues se generan flujos más granulares (por ejemplo, cada conexión TCP) y la distribución tiende a equilibrarse mejor.

Una posible mitigación en escenarios de sesgo consiste en controlar el orden de arranque de las máquinas virtuales, agrupando aquellas que comparten pesos similares. Como la formación de equipos aplica hashes a las vNIC de forma round-robin, iniciar las VMs por bloques puede ayudar a mantener una distribución de pesos más uniforme entre las NIC del equipo.

Problemas parecidos pueden darse con el ancho de banda mínimo aplicado por hardware vía DCB si el algoritmo de distribución de tráfico está sesgado. También, cuando se usa ancho de banda mínimo absoluto (BPS) con un equipo de NIC, hay que tener cuidado con la suma total: si el conmutador Hyper-V está conectado a un equipo de dos NIC de 1 Gb (2 Gb agregados), no se debe asignar más de 1 Gb a una VM, porque si una NIC falla solo quedará 1 Gb disponible. En estos casos, el modo de peso simplifica la gestión, ya que el ancho de banda restante se reparte proporcionalmente sin violar garantías absolutas.

Cuándo merece la pena preocuparse por QoS Packet Scheduler

En redes corporativas donde ya se ha desplegado QoS extremo a extremo y se usan softphones, videoconferencias y aplicaciones críticas, tiene todo el sentido dedicar tiempo a definir políticas de QoS en Windows. Se pueden asociar a ejecutables (por ejemplo, el cliente de Avaya o cualquier otro softphone), marcar DSCP y/o limitar tasas, y todo ello desplegado por GPO.

En el lado del usuario doméstico, que utiliza Windows 10 sobre una red casera poco sofisticada, gran parte de esas marcas DSCP y prioridades probablemente se pierdan en el camino, porque muchos routers de gama baja ignoran por completo el QoS avanzado o lo implementan de forma muy básica. Aun así, en el tramo de la red de empresa (por ejemplo, a través de VPN) sí se pueden aprovechar las políticas definidas a nivel corporativo.

De cara a la típica duda de “¿Windows sabe que mi aplicación de VoIP es VoIP y la mete sola en el 20% reservado?”, la respuesta corta es que no: es el administrador quien debe definir las políticas pertinentes. Windows ofrece las herramientas (Packet Scheduler, políticas QoS, marcado DSCP, limitación, etc.), pero no “adivina” mágicamente qué tráfico es prioritario, salvo que la propia aplicación utilice APIs de QoS y marque su tráfico.

En lugar de desactivar el Programador de Paquetes QoS o tocar parámetros sin saber muy bien qué hacen, tiene mucho más sentido usarlo a tu favor para priorizar correctamente el tráfico clave, y combinarlo con las capacidades de QoS de la red (routers, switches, DCB, WMM, etc.).

QoS Packet Scheduler, las políticas de QoS en Windows, el uso de DSCP, la gestión de ancho de banda mínimo en Hyper-V, la integración con DCB y la formación de equipos de NIC conforman un ecosistema bastante completo que, bien usado, permite que voz, vídeo y aplicaciones críticas se mantengan fluidas incluso cuando el resto del tráfico intenta saturar la red; y todo ello sin dejar realmente trozos de ancho de banda sin usar, sino ajustando dinámicamente prioridades y repartos según las reglas definidas.