Resumen

  • RFC 3432 elegía T0 al azar dentro de una ventana y después enviaba con intervalo nominal incT hasta Tf; el inicio mitigaba anticipación y cierta sincronización, pero no convertía la muestra periódica en una muestra sin sesgo.
  • El resultado debía conservar Type-P, umbral que convierte demora en pérdida, reglas de singleton válido, calibración, camino y condiciones de fondo. Un promedio aislado no describía toda la red.

Un sorteo seguido de un metrónomo

Una herramienta espera en una ventana, sortea el instante de arranque y, desde allí, emite cada veinte milisegundos. El origen de fase cambia; el ritmo permanece.

RFC 3432, de noviembre de 2002, formalizó esa idea. El texto, la ficha RFC Editor, la página IETF, su historial, las referencias y la consulta de erratas registran un método Standards Track, no una medición de una red real.

Paquetes iguales o casi iguales a intervalos regulares imitaban flujos CBR o multimedia. La densidad permitía ver fenómenos breves relevantes para voz o conferencia.

El sesgo conocido respondía una pregunta concreta

El marco de RFC 2330 advertía que los singleton regulares solo muestrean una parte del espectro. RFC 3432 aceptó que Poisson produce una muestra general sin sesgo y que la periodicidad introduce sesgo.

Ese sesgo podía interesar. Si la pregunta es qué sufre un flujo multimedia de cierta cadencia, reproducirla delimita bien el experimento. Lo incorrecto es quitar la etiqueta y presentarlo como diagnóstico universal.

Una perturbación periódica puede coincidir siempre o caer siempre entre sondas. El flujo puede ser anticipado y el tráfico activo puede sincronizar emisores o congestionar. Sortear independientemente T0 dentro de [T,T+dT] y limitar la duración mitigaba algunos riesgos; no aleatorizaba cada incT.

Type-P formaba parte del resultado

La métrica era Type-P-One-way-Delay-Periodic-Stream. Type-P incluía versión IP, protocolo, puerto, tamaño, precedencia o tratamiento especial. Cambiar el paquete podía cambiar colas, ruta y resultado.

Las pruebas activas con varios tamaños debían reproducir la distribución prevista. RFC 2679 y su actualización RFC 7679 dan contexto de demora; RFC 2680 y RFC 7680, de pérdida. Ninguna permite que una sonda pequeña privilegiada represente en silencio otro tráfico.

Lo no medible no valía cero

Los puntos fuente y destino reunían timestamps, identificadores y tamaños. Un estado opcional podía distinguir cabecera corrupta, payload corrupto, duplicado o fragmento, si se publicaba el criterio.

La demora era timestamp de destino menos timestamp de fuente. No existía para un paquete espurio sin salida, no recibido sin llegada o con cabecera corrupta. Entre duplicados solo la primera copia no corrupta obtenía valor.

El promedio usaba solo singleton válidos. La variación entre adyacentes quedaba indefinida si faltaba uno. RFC 3393 y RFC 5481 desarrollan esas distinciones. Una media baja puede ocultar que los casos peores salieron del denominador.

La pérdida empezaba en dTloss

Mientras la ventana siga abierta, un paquete ausente puede ser solo tardío. dTloss fijaba el máximo de espera antes de interpretar la demora como pérdida. El valor o método debía publicarse.

Para tiempo real, llegar tras el playout puede equivaler a perder; para otra aplicación, no. RFC 6673 y RFC 6534 muestran que la observación forma parte de la métrica. Dos umbrales pueden contar distinta pérdida sobre las mismas llegadas.

También se medía el medidor

Sincronización, resolución y deriva de relojes afectaban la demora unidireccional. El timestamp del host no era exactamente el tiempo en el cable. La carga de CPU, el scheduler y el I/O podían deformar incT y aumentar error aleatorio.

RFC 3432 pedía quitar error sistemático conocido y reportar error de calibración e con confianza del 95 %. La calibración debía repetirse bajo carga semejante a campo. RFC 7312 ofrece contexto posterior; RFC 2119 explica los términos normativos empleados para comparabilidad.

Cinco contextos acompañaban la cifra

Type-P, umbral demora-pérdida, calibración, camino y condiciones de fondo debían viajar con el informe. El camino preciso suele ser incognoscible; Record Route puede alterar el procesamiento común. Aun un dato parcial como el enlace inicial ayuda.

Nivel IP tampoco equivale a codec, sistema operativo o experiencia humana. Pérdidas en ráfaga, demora, duplicación, reordenamiento y corrupción tienen efectos específicos.

Fuentes y límites

La lectura aplica a Heng Lu sobre capas de realidad y código en ejecución. Definición, paquete, observación, singleton calibrado, agregado y resultado humano no son intercambiables.

Las fuentes no demuestran despliegue actual, ruta nombrada, fallo medido, QoS, manipulación ni experiencia universal. Definen la honestidad necesaria para una muestra periódica.