Resumen

  • El formato de observación conservaba paquetes, mediciones del dispositivo, ubicación y anotaciones; PaM empleaba un formato distinto y reducido para imponer alteraciones al tráfico.
  • La transformación descrita usaba sondas ICMP pequeñas y grandes, una única referencia de reloj y ventanas ajustables. La repetibilidad correspondía a ese experimento construido, no a todos los fenómenos de la red original.

Dos archivos, dos compromisos

Un archivo puede decir qué ocurrió durante un recorrido sin indicar todavía cómo reproducirlo. Un segundo archivo puede mandar al núcleo de un sistema que retrase o descarte paquetes, pero ya no conservar todas las circunstancias de la observación. RFC 2041 situó el trabajo experimental en la relación entre ambos: el registro debía permitir comprender una experiencia concreta; la conversión debía seleccionar de ella restricciones que otro ordenador pudiera ejecutar.

Mobile Network Tracing, publicado en octubre de 1996, presentaba investigación inicial de Brian D. Noble, Giao T. Nguyen, Mahadev Satyanarayanan y Randy H. Katz, con afiliaciones a Carnegie Mellon University y University of California, Berkeley. Su condición era informativa, no de estándar de Internet. Proponía compartir un formato y exponía herramientas de investigación. Leerlo como garantía de una técnica universal borraría precisamente las cautelas que hacen útil el documento.

La escena de partida era un equipo móvil instrumentado que recorría un camino mientras una carga conocida, procedente de un equipo fijo, generaba tráfico. Repetir recorridos con distintas cargas permitía reunir una familia de trazas para ese camino. El tiempo, la ruta y la carga seguían formando parte de la evidencia. La colección no representaba por sí sola a todos los usuarios ni a cualquier entorno inalámbrico.

La descripción acompaña a las mediciones

Para compartir esas observaciones, el RFC buscaba extensibilidad, autodescripción y facilidad de gestión. Las pistas agrupaban registros relacionados. Una pista de paquetes podía delimitar un protocolo o una parte del tráfico; una de dispositivo, sus mediciones; una general, posiciones. El encabezado de cada pista debía preceder a sus entradas, aunque los registros de varias pistas podían intercalarse. La sección 4.1 explica cómo las propiedades distinguían información fija del encabezado y valores variables de cada entrada.

Ese diseño permitía localizar y saltar una propiedad desconocida. Resultaba importante para que una herramienta antigua no perdiera acceso a todo el archivo cuando aparecieran campos nuevos. Pero saltar un valor no equivalía a comprenderlo. La compatibilidad estructural no establecía que una traza fuera adecuada para calcular un parámetro determinado.

Los registros contenían un identificador de tipo de 32 bits y su tamaño, almacenados en orden de red. La combinación ayudaba a comprobar que la estructura tenía sentido. No era una firma del origen ni una prueba de que la medición fuera correcta. El encabezado de la traza describía su procedencia y referencia temporal; el cierre marcaba el final del archivo. Un archivo cerrado todavía podía contener huecos de observación.

El reloj fija qué comparación es posible

El formato admitía segundos con microsegundos o segundos con nanosegundos, utilizando una sola modalidad en cada traza. Esas unidades indicaban la granularidad de la representación. No prometían exactitud de reloj, sincronización entre máquinas ni capacidad del planificador para ejecutar demoras con esa precisión.

Cada pista de paquetes identificaba el equipo, el dispositivo y el protocolo. Las entradas anotaban tamaño y hora de envío o recepción, más las propiedades seleccionadas. Los números de secuencia ayudaban a estudiar patrones de pérdida. Para obtener tiempos en un solo sentido con marcas de dos equipos, sus relojes debían estar estrechamente sincronizados. La propiedad ICMP_PINGTIME correspondía, en cambio, a ida y vuelta. La sección 4.3 no permite intercambiar esas dos clases de evidencia.

También había que interpretar el dispositivo en sus propios términos. WaveLAN ofrecía datos de señal, ruido o calidad, con significado dependiente del hardware. Muchas mediciones se promediaban y se muestreaban periódicamente. Superponer una caída de señal y un aumento de pérdidas podía orientar una investigación, pero no probar por sí solo la causa. Ciertos estados de error, como CRC o desbordamiento del búfer de interfaz, aportaban pistas sobre algunos fallos, sin explicar automáticamente todos los demás.

Lo que falta pertenece al resultado

La localización tampoco era una observación perfecta. Los autores habían desarrollado una herramienta gráfica para indicar posiciones interiores mediante clics en un mapa; consideraban GPS para exteriores. La estación de base podía servir como aproximación imprecisa a la posición, si esa información estaba disponible. Las anotaciones añadían texto con hora y equipo de origen, fuera de las pistas. Ayudaban a interpretar un recorrido sin convertirlo en un registro continuo de todo su contexto.

El tratamiento de los datos ausentes era especialmente revelador. La sección 4.7 incorporaba un registro para contar categorías de datos perdidos durante la captura: encabezados y entradas de paquetes o dispositivos, y anotaciones. Un desbordamiento del sistema de registro podía borrar una observación incluso cuando el paquete hubiera circulado.

Por eso, perder un registro y perder un paquete son hechos diferentes. El contador reconoce el daño de la captura, pero no reconstruye la secuencia que desapareció. La recogida mediante un agente del núcleo y un colector de usuario, con transferencias agrupadas y escritura posterior, amortizaba costes. No justificaba afirmar que observar carecía de sobrecarga o que la captura estaba completa.

Un programa de restricciones para el software

PaM interceptaba tráfico entrante y saliente entre IP y las interfaces. Podía no reenviar un paquete, cambiar bits o retrasarlo. La aplicación sometida a prueba no necesitaba cambios en el código fuente ni en el binario. Esa transparencia facilitaba probar su conducta ante condiciones impuestas, manteniendo intacto el software que se quería estudiar.

El modelo de la sección 5.2.1 representaba la demora como tiempo de transmisión, dependiente del tamaño y del ancho de banda disponible, más latencia. Suponía una red subyacente suficientemente rápida y fiable para despreciar su contribución. Como el reloj interno tenía una resolución gruesa, se buscaba reducir el error medio de programación, no reproducir el instante exacto de cada paquete.

Las entradas de modulación fijaban parámetros durante intervalos: latencia, tiempo entre bytes —inverso del ancho de banda— y tasas de pérdida y corrupción. Las unidades y escalas se declaraban en el encabezado. Era una representación deliberadamente más sencilla que la observación original. La ubicación y el contexto del dispositivo no se transformaban íntegramente en acciones del núcleo. El laboratorio recibía restricciones ejecutables, no el entorno físico entero.

La estrecha puerta de la conversión

La transformación implementada se limitaba a una clase muy específica de trazas. Su hipótesis era que dos paquetes de distinto tamaño, enviados próximos en el tiempo por el mismo camino, experimentaban igual latencia y ancho de banda. A partir de sus tamaños y tiempos, se estimaban esos parámetros. La cercanía temporal no demostraba esa igualdad; era el supuesto que hacía posible el cálculo. La sección 5.2.3 explicita esta restricción.

Los relojes de los portátiles disponibles derivaban de manera apreciable. En aquellos experimentos, los autores evitaron NTP tanto por el tráfico adicional como por los ajustes del reloj. Usaron una sola máquina para medir la salida de solicitudes ICMP ECHO y la llegada de sus respuestas. Un ping modificado alternaba paquetes pequeños y grandes. Así obtenían una referencia común para tiempos de ida y vuelta, sin resolver por separado los tiempos de cada dirección.

Una ventana móvil calculaba la pérdida y los promedios de latencia y ancho de banda de las parejas. Tamaño y paso eran ajustables; los autores todavía esperaban adquirir experiencia antes de recomendar valores. Una ventana corta dispone de menos muestras y puede conservar variaciones; una larga puede suavizar episodios breves. Es una consecuencia analítica de esa elección, no un resultado numérico universal del RFC.

Además, el hardware descartaba paquetes corruptos sin notificarlos al sistema operativo. PaM podía convertir corrupción en pérdida para imitar ese comportamiento visible, no extraer una historia de corrupción que el dispositivo no había observado. La misma disciplina se aplica a los trabajos futuros de la sección 7: escenarios de varios equipos, direcciones separadas, interfaces múltiples y destinos distintos seguían abiertos. El formato seguía centrado en IP; representar con mayor comodidad otros esquemas de direccionamiento era todavía una extensión pendiente. Poder fusionar archivos no demostraba un modelo de ancho de banda compartido.

La prueba repetible quedaba, por tanto, compuesta por observaciones con procedencia, una conversión declarada y una configuración de ejecución. El resultado servía para evaluar software bajo ese calendario de restricciones. Su repetición no ampliaba retrospectivamente lo observado en el recorrido.

Fuentes