Establece un presupuesto de retardo para el tráfico en tiempo real por VPN
Parta del plazo que la aplicación debe cumplir y mida después el retardo de ida y el jitter en condiciones declaradas. Una media sin umbral de tardanza no demuestra nada.
Las quejas sobre VPN en tiempo real necesitan un plazo contra el que fallar, y «baja latencia» no lo es. Decida qué debe entregar la conversación o la sesión remota y luego mida la ruta frente a ese requisito en condiciones declaradas. Sin un umbral de paquetes tardíos, cualquier resultado es discutible. La asignación de abajo es una decisión de diseño y existe para que la medición tenga algo que responder.
Escriba el plazo antes de tocar una sonda
El plazo viene de la aplicación y de sus usuarios, no de la página de marketing de un proveedor. Una llamada de voz en directo, una sesión de escritorio remoto y una copia de seguridad nocturna toleran tiempos de espera completamente distintos, y el fallo que importa suele ser la cola y no la mediana. Escriba el número junto con la carga de trabajo a la que pertenece.
Después repártalo. La captura y la paquetización consumen parte del presupuesto, el enlace de acceso y el túnel otra parte, el búfer de des-jitter del receptor retiene paquetes a propósito y el procesamiento de la aplicación toma el resto. Nombrar esas etapas mantiene el cifrado del túnel en proporción en lugar de convertirlo en el sospechoso por defecto de cada paquete lento.
Por último defina el contrato de medición en cuatro líneas: extremos y dirección, forma del tráfico, condiciones durante la ejecución y el resultado que va a informar. Una muestra de un domingo tranquilo y una del martes cargado responden a preguntas distintas, así que indique cuál recogió. Si no puede rellenar las cuatro líneas, la ejecución no está lista para empezar. Esa lista de comprobación es también lo que hace comparables dos informes meses después, cuando ya nadie recuerda qué más llevaba el enlace.
Reparta el presupuesto entre cada etapa
La tabla es una ayuda de planificación, no datos capturados. Rellene el propietario de cada fila antes de la primera sonda, porque el propietario es a quien llama cuando esa etapa supera su parte.
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
Dos filas suelen sorprender a la gente. El búfer del receptor no es un fallo cuando añade retardo, porque hace el trabajo para el que se configuró. Y la parte del túnel suele ser menor que la cola que tiene delante, sobre todo en un enlace de subida que se satura durante las cargas.
Cuando una etapa no tiene propietario, el presupuesto es ficción. Asigne uno antes de medir, o pasará la reunión siguiente discutiendo qué número es el equivocado.
Mida el retardo de ida con un reloj honesto
El retardo de ida es el número que le importa al plazo, y necesita relojes sincronizados en ambos extremos. La métrica de retardo de ida exige informar del método de sincronización, la resolución y la desviación estimada junto al resultado. Dos hosts no sincronizados pueden producir un número muy preciso para la cantidad equivocada.
Capture unos cientos de paquetes en lugar de un puñado y anote el estado del reloj al mismo tiempo:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3El tiempo de ida y vuelta es una medición aparte, no dos valores de ida sumados. Dividir un RTT por la mitad supone rutas simétricas y colas simétricas, y un túnel sobre un enlace móvil de subida rompe ambas suposiciones con regularidad. Informe el RTT como RTT y manténgalo fuera del presupuesto de ida.
Informe de la cola y de los paquetes tardíos
Resuma la distribución: mediana, percentil 95 y 99, peor caso, pérdida y el número de paquetes que llegaron más tarde de lo que el plazo permite. La media es el menos útil de esos números para una carga en tiempo real, porque una media uniforme puede ocultar una cola que arruina cada tercera llamada.
La variación del retardo alimenta directamente el búfer del receptor. Más búfer oculta la variación y añade espera, así que un flujo puede parecer estable mientras supera su plazo. Elija una formulación de la variación, indique el intervalo sobre el que midió y manténgala coherente entre ejecuciones.
Repita la ejecución con tráfico cruzado representativo. Una ruta que cumple el presupuesto cuando está inactiva y lo incumple durante una ventana de copia de seguridad le ha dicho algo útil sobre la planificación, que ninguna medición tranquila aislada revelaría. Anote las condiciones junto al resultado, porque el siguiente ingeniero, si no, comparará dos muestras que nunca fueron comparables.
Acepte el diseño cuando la cola medida encaje en el presupuesto bajo la carga de trabajo que realmente ejecuta, y rechívelo con la etapa que se excedió nombrada en el informe.