Compara tu pérdida de paquetes con los objetivos de la UIT-T. Ve el rendimiento que te deja y qué aplicaciones siguen dentro de su objetivo.
Límites tomados de la Tabla 1 de la UIT-T Y.1541 (tasa de pérdida de paquetes IP para las clases de QoS 0 a 4) y de los objetivos por aplicación de la Tabla I.1 de la UIT-T G.1010.
| Banda | Pérdida de paquetes |
|---|---|
| Sin pérdida | 0 |
| Dentro de los límites de clase UIT | hasta 0,1 % |
| Tiempo real aún cumple | hasta 1 % |
| Solo voz | hasta 3 % |
| Fuera de todos los objetivos publicados | más de 3 % |
Tablas I.1 y I.2 de la UIT-T G.1010. Los objetivos de audio y vídeo suponen un algoritmo de ocultación de pérdida de paquetes; todas las aplicaciones de datos tienen como objetivo pérdida de información cero, porque TCP tiene que retransmitir lo que se descarta.
| Aplicación | Objetivo |
|---|---|
| Llamadas de voz (VoIP) | Objetivo: menos de 3 % |
| Videollamadas | Objetivo: menos de 1 % |
| Audio y vídeo en streaming | Objetivo: menos de 1 % |
| Juegos interactivos | Objetivo: pérdida cero |
| Shell remoto y control | Objetivo: pérdida cero |
| Navegación web | Objetivo: pérdida cero |
| Transferencias de archivos | Objetivo: pérdida cero |
| Correo electrónico | Objetivo: pérdida cero |
También podrías encontrar útiles estas calculadoras
Calcula el producto ancho de banda-retardo y la ventana TCP necesaria
Mide el jitter de red desde ping: PDV, tamaño de búfer y límites de la UIT
Calcula la latencia de red: retardos de propagación, transmisión y proceso
Cuánta velocidad necesitas y cuánto tarda una transferencia
Casi todas las respuestas a esa pregunta son opiniones de un foro. Existen respuestas publicadas. La UIT-T Y.1541 fija una tasa de pérdida de paquetes IP de 0,1 % como límite superior para todas las clases de QoS de red especificadas, y la UIT-T G.1010 fija un objetivo para cada tipo de aplicación: menos de 3 % para voz conversacional, menos de 1 % para vídeo y streaming, y cero para navegación web, transferencia de archivos, correo y tráfico interactivo. Introduce la pérdida que mediste y esta calculadora la evalúa contra esos objetivos, y luego muestra el rendimiento que TCP puede alcanzar realmente con esa tasa.
La pérdida de paquetes es la proporción de paquetes que nunca llegan. TCP interpreta cada pérdida como congestión y baja su tasa de envío, así que el rendimiento cae mucho más rápido de lo que sugiere la tasa de pérdida por sí sola: escala con la inversa de la raíz cuadrada de la probabilidad de pérdida, no de forma lineal. Esa relación es la ecuación de Mathis, y explica por qué 1 % de pérdida puede costar mucho más que 1 % de tu ancho de banda. La ecuación es una aproximación de estado estacionario: el RFC 3649 la restringe a pérdidas de 1 % o menos, así que por encima de eso esta página marca la cifra como una extrapolación en lugar de imprimirla sin más.
Ecuación de Rendimiento de Mathis
Determina si la pérdida que mediste está dentro del límite de clase de red de la UIT o muy por encima antes de abrir un ticket.
Comprueba un enlace candidato contra los objetivos de la G.1010 para voz conversacional y videollamada antes de comprometerte con él.
Muestra por qué un enlace de un gigabit entrega una fracción de su velocidad en una ruta larga con algo de pérdida.
Combina un tiempo de ida y vuelta alto con una tasa de pérdida pequeña para ver el techo que TCP alcanzará sin importar el circuito.
Pregunta qué pérdida de paquetes es aceptable y tres fuentes distintas te dirán 1 %, 2 % y 5 %. La UIT-T G.1010 y la Y.1541 publican cifras concretas, por aplicación y por clase de red.
El rendimiento cae con la raíz cuadrada de la tasa de pérdida. En una ruta larga, una fracción de un por ciento puede dejar un enlace de un gigabit en unos pocos megabits, y por eso una prueba de velocidad decepciona mientras el ping se ve bien.
La voz tolera más pérdida que el vídeo. Una transferencia de archivos tolera la pérdida en el sentido de que igual termina: solo se vuelve más lenta. Evaluarlas todas en una sola escala oculta esa diferencia.
Una norma citada por su nombre y una tasa medida convencen mucho más a un proveedor que una descripción de los síntomas.
Para la red en sí, la UIT-T Y.1541 fija una tasa de pérdida de paquetes IP de 0,1 % como límite superior para las clases de QoS 0 a 4. Para las aplicaciones, la UIT-T G.1010 fija menos de 3 % para voz conversacional, menos de 1 % para videollamada, vídeo unidireccional y audio en streaming, y pérdida de información cero para navegación web, transferencias masivas, correo, juegos interactivos y control remoto. Cualquier valor igual o inferior a 0,1 % es aceptable según todas esas medidas.
Sí, según la norma. La UIT-T G.1010 clasifica los juegos interactivos junto con el tráfico de comando y control, cuyo objetivo es pérdida de información cero y menos de 200 ms de retardo unidireccional. Los juegos no se evalúan con una banda de tolerancia como la voz, porque una actualización perdida no se oculta: es una entrada que no se registra o una corrección de posición. Con 1 % ya superaste el objetivo, y superaste diez veces el límite de clase de red de 0,1 %.
Es grave. Con 10 % ninguna categoría de aplicación de la UIT-T G.1010 está dentro de su objetivo, incluida la voz conversacional, y el rendimiento de TCP se desploma: la relación de Mathis deja un MSS de 1460 bytes en una ruta de 50 ms alrededor de 900 Kbps, sin importar la velocidad de la línea. Una pérdida de este nivel suele ser una falla de hardware o de línea, no congestión que puedas ajustar.
En una conexión por cable sana, prácticamente cero: una ruta bien mantenida no muestra pérdida en un ping de 100 paquetes. La UIT-T Y.1541 indica que su objetivo de 0,1 % es alcanzable en implementaciones habituales de redes IP, así que trata 0,1 % como el techo de lo normal y no como la expectativa. Algo de pérdida ocasional en Wi-Fi o en un enlace móvil es común y no es por sí sola una falla.
TCP interpreta la pérdida como congestión y reduce su ventana, así que la tasa sostenible escala con la inversa de la raíz cuadrada de la probabilidad de pérdida y no con la pérdida misma. El tiempo de ida y vuelta multiplica el efecto, porque el emisor espera un viaje completo antes de poder volver a agrandar la ventana. Por eso ese mismo 1 % de pérdida apenas afecta un enlace dentro de un centro de datos y arruina uno intercontinental.
Ejecuta ping con una muestra grande: 'ping -c 100 8.8.8.8' en macOS o Linux, 'ping -n 100 8.8.8.8' en Windows, y lee el porcentaje de pérdida en la línea de resumen. mtr y pathping además muestran qué salto está descartando paquetes, lo cual importa porque la pérdida en un salto intermedio suele ser el router despriorizando sus propias respuestas de ping y no una pérdida real de reenvío.
Es la causa más común en casa. La interferencia, la distancia y la competencia con redes vecinas producen pérdida que el Ethernet por cable no tiene. Probar la misma ruta por cable es la forma más rápida de establecer si la pérdida está en tu último metro o más arriba.
Prueba con Ethernet por cable para descartar el Wi-Fi, reemplaza cables viejos y revisa que no haya discrepancias de dúplex, y aplica QoS para que el tráfico en tiempo real no quede en cola detrás de transferencias masivas. Si la pérdida persiste por cable hacia varios destinos, está más arriba: captura un mtr con marca de tiempo y repórtalo. Reducir el MSS solo ayuda cuando la pérdida la causa la fragmentación en una ruta con MTU menor.