RFC 2063: el tráfico contado durante el silencio del lector

Resumen

• Si fallaba únicamente el lector y el medidor conservaba un estado comparable, los contadores acumulativos podían permitir recuperar el volumen. Las lecturas omitidas dejaban una pérdida de resolución temporal (RFC 2063, §2.5).
• La recuperación dependía de la identidad del flujo, sus reglas, la retención y los límites del contador. Añadir lectores protegía la recogida; añadir medidores protegía frente a otro tipo de fallo (RFC 2063, §§2.5, 3.2 y 4.5).

Imaginemos un caso hipotético: el único lector se detiene, mientras el medidor continúa contando. Al regresar, encuentra un total mayor. Si conserva la lectura anterior y siguen siendo comparables el flujo, las reglas y el contador, puede calcular el incremento entre ambas observaciones. Queda sin resolver cómo se distribuyó ese tráfico dentro del intervalo. El total sería compatible con ritmos distintos, incluidas ráfagas breves. Esta es una deducción del mecanismo descrito en RFC 2063, §§2.5 y 3.3, no el relato de una avería documentada.

Quién conservaba cada parte de la evidencia

Publicado en enero de 1997, RFC 2063 llevaba las firmas de Nevil Brownlee, de The University of Auckland; Cyndi Mills, de BBN Systems and Technologies; y Greg Ruth, de GTE Laboratories, Inc. La arquitectura experimental de medición de flujos en tiempo real organizaba información, requisitos y decisiones de implementación, sin constituir un estándar de Internet ni una especificación de protocolo (RFC 2063, encabezamiento y §1).

Su flujo era una construcción lógica que agrupaba tráfico de una entidad entre un comienzo y un final. Las reglas clasificaban paquetes IP independientes mediante sus atributos. La entidad podía ser un usuario, equipo, red o grupo, según la granularidad; esa atribución no autenticaba a un pagador contractual. Cada paquete contabilizado pertenecía a un único flujo. Para obtener vistas solapadas, hacían falta categorías disjuntas más finas y procesamiento posterior (RFC 2063, §§2.1 y 3.3).

El gestor fijaba reglas, granularidad, muestreo, límites de tabla e inactividad; también indicaba al lector qué medidor consultar, con qué intervalo y qué flujos y atributos recoger. El medidor mantenía cantidades acumuladas de paquetes y bytes; el lector transportaba los datos para analizarlos. Estas funciones podían compartir máquina. La arquitectura de 1997 asignaba un único gestor de control a cada medidor o lector (RFC 2063, §§2.1–2.4).

El tiempo del flujo y el tiempo de la lectura

El RFC recomendaba contadores continuos, sin ponerlos a cero tras cada lectura; así, una observación posterior podía cubrir cantidades omitidas antes. Para comparar valores había que identificar el medidor, el conjunto de reglas mediante su Rule Set ID y el flujo: su hora de inicio ayudaba a distinguirlo de otro creado con las mismas direcciones. La resta exigía estado conservado y ausencia de vueltas ambiguas del contador; volver a leer un total tampoco autorizaba a sumarlo como tráfico nuevo (RFC 2063, §§3.2–3.3).

El medidor guardaba los momentos del primer y último paquete. Por su parte, el lector almacenaba archivos en disco por medidor, con registros que incluían identidad del medidor, marca temporal, identificador de las reglas de recogida, descriptores y cantidades (RFC 2063, §§3.1 y 5.2). De ahí se deduce el límite: los extremos de actividad acotan el flujo, pero no reconstruyen sus pasos intermedios. Una aplicación podría calcular una tasa media entre observaciones comparables; atribuirle una curva detallada exigiría información adicional.

Varios lectores, observaciones distintas

La lectura podía abarcar toda la tabla, determinadas filas o ciertos atributos, sin sincronización obligatoria. Dos lectores con igual periodicidad y distinta fase podían obtener cifras diferentes sin corrupción. Sus registros acumulativos solapados requerían conciliación. Los lectores redundantes protegían la continuidad de la recogida; los medidores redundantes sobre un mismo segmento, la continuidad de la medición (RFC 2063, §§2.2 y 2.5).

La MIB experimental contemporánea permitía recorridos con índices sin estado compartido de lectura y consultas de cambios mediante TimeFilter y GetBulk. Sus variables flowReaderLastTime y flowReaderPreviousTime orientaban la liberación de memoria; flowReaderTimeout permitía retirar el registro de un lector atrasado. La escritura de LastTime iniciaba una recogida, sin certificar una instantánea atómica de toda la tabla. Incluso podía seguir leyéndose cuando un fallo de escritura o autenticación entorpecía la liberación. La MIB ya distinguía un gestor principal y contemplaba aproximar una instantánea cambiando de reglas en un medidor (RFC 2064, §3.2 y definiciones de la MIB).

La recuperación terminaba donde terminaba el estado

RFC 2063 exigía que al menos un lector recogiera un flujo inactivo antes de liberar su registro, pero dejaba pendiente desarrollar mejor la política para varios lectores. LastCollectTime y el plazo de inactividad intervenían en la retención. Ante presión de memoria, contemplaba reglas de reserva menos detalladas, intervalos de recogida más cortos e incluso pérdidas breves para mantener funcionando el medidor (RFC 2063, §§3.2, 4.5–4.6 y 5.3).

Si se interrumpía el gestor, medidores y lectores debían seguir trabajando. Una parada prevista del medidor podía motivar una recogida final; tras un reinicio imprevisto, un aviso o el sondeo del lector podían impulsar la recarga de reglas. Los avisos propuestos no garantizaban entrega ni autenticidad, y recargar la configuración no recuperaba estado desaparecido ni tráfico que hubiera quedado sin medir (RFC 2063, §6.3).

En octubre de 1999, la revisión informativa RFC 2722 sustituyó a RFC 2063. Conservó la advertencia sobre resolución temporal y precisó la política de esperar a todos los lectores registrados antes de liberar un flujo, salvo lectores retirados del registro por vencimiento del plazo. También admitió conjuntos de reglas y gestores concurrentes. Alternar dos copias idénticas de reglas en un medidor permitía recoger registros iguales del conjunto anterior; no garantizaba conmutación simultánea entre medidores (RFC 2722, §§2.3, 2.5 y 4.5). Son precisiones posteriores, no garantías atribuibles a toda implementación de 1997.

La arquitectura dejaba las tarifas y la recuperación de costes fuera de alcance. Admitía SNMP sin fijar el transporte y confiaba la integridad y confidencialidad a los protocolos de gestión y recogida. Medir cantidades tampoco acreditaba entrega útil, autorización tarifaria, validez de una factura o pago (RFC 2063, §§1, 5.3 y 10).

Fuentes y alcance de la interpretación

Documentos de 1997. RFC 2063: arquitectura de medición de flujos fundamenta el mecanismo y sus condiciones. RFC 2064: base de información de gestión del medidor documenta la recogida y el seguimiento de lectores.

Estado documental. La ficha oficial de RFC 2063 registra su categoría experimental y sustitución por RFC 2722. La consulta oficial de erratas de RFC 2063 no registra coincidencias; eso no demuestra ausencia de defectos. Estos registros no acreditan despliegue actual ni compatibilidad comercial.

Antecedente y revisión. RFC 1272: fundamentos de la medición de flujos, de noviembre de 1991, expone la justificación arquitectónica y separa medición y política económica. RFC 2722: arquitectura revisada y RFC 2720: MIB posterior del medidor, de octubre de 1999, aportan contexto posterior.

Lecturas editoriales posteriores. Lu Heng distingue publicación y funcionamiento observado en su ensayo sobre la primacía del código en funcionamiento. Su reflexión sobre reglas iniciales mínimas y decisiones locales permite examinar aquí la separación entre significados comunes y elecciones locales de intervalos y retención. Su texto sobre la realidad como criterio editorial de BTW.Media propone describir estructuras y supuestos sin promover soluciones. Son marcos interpretativos posteriores de Lu Heng, no pruebas de comportamiento técnico ni de las intenciones de los autores de 1997.