Resumen

  • RFC 3116 pidió timestamps de transmisión y recepción correlacionables, alimentados por un reloj común, y exigió declarar longitud, precisión y valor de reinicio del contador.
  • La demora dependía además del número de VCC, clase portadora, tasa, ráfagas e intervalo de observación. El resultado describía una prueba controlada, no la experiencia de una aplicación.

Un intervalo tenía más de dos extremos

RFC 2761 definió Cell Transfer Delay como el tiempo entre la salida de una celda en un punto de medida y la entrada de esa misma celda en otro. RFC 3116 convirtió esa definición en procedimiento. Su problema no era escribir la resta, sino demostrar que los dos términos pertenecían al mismo eje temporal y al mismo evento.

La metodología, publicada en junio de 2001 como Informational, recomendó una señal de reloj común de al menos 100 MHz, o resolución de 10 ns, para transmisor y receptor. La celda de prueba debía contener una marca de transmisión correlacionable con la observación de llegada. La opción preferida era una celda O.191 dentro de un paquete IP válido.

Los contadores tenían un tamaño finito. Al llegar al máximo volvían a cero. Si el paquete salía antes del giro y llegaba después, una resta sin época podía producir un valor negativo o gigantesco. Por eso había que registrar el máximo del timestamp. La descripción de cualquier celda de prueba debía incluir longitud en bits, valor de rollover y precisión en nanosegundos.

El dato de rendimiento empezaba en el instrumento, antes de entrar en el conmutador. Una cifra con muchos decimales no resolvía la identidad del reloj, el punto físico de captura ni la continuidad del contador.

Compartir frecuencia no resolvía toda la medida

Una referencia común reducía la deriva relativa, pero no certificaba fase, cableado ni latencia de captura. El transmisor podía marcar el evento antes de que la celda cruzara el punto elegido. El receptor podía hacerlo después. La electrónica y el software de correlación seguían aportando demora e incertidumbre.

RFC 2679 expresó la misma disciplina para la demora IP unidireccional: separó sincronización, exactitud, resolución y skew, y distinguió tiempo del host de tiempo en el cable. RFC 2330 fijó el marco IPPM; RFC 7679 reemplazó después a RFC 2679 manteniendo la obligación de tratar la incertidumbre.

No son la misma prueba. IPPM observaba paquetes sobre un camino; RFC 3116 caracterizaba equipos ATM con celdas y configuraciones controladas. La comparación sirve para ver una decisión histórica común: el reloj era parte de la evidencia, no un fondo invisible.

Decir “100 MHz” no equivalía a probar 10 ns de exactitud total. Era una propiedad requerida de la referencia. La exactitud de las marcas y su relación con los eventos de salida y entrada debían conservarse aparte.

La cola también escribía el resultado

Un conmutador no tarda lo mismo bajo cualquier carga. Una celda puede esperar mientras se atienden otras conexiones. Una ráfaga encuentra colas distintas a las de un flujo regular. RFC 2761 vinculó Cell Delay Variation con carga, orientación, distribución e intervalo de integración.

RFC 3116 probaba uno, doce y el máximo de VCC admitidos. Distinguía carga constante, UBR a ráfagas, VBR y mezcla de clases. El informe debía exponer tamaño y tasa de paquetes, clase portadora, VPI/VCI, PCR, SCR y MBS. Cuando la prueba no era de throughput, la tasa no debía superar el 90 % de la línea.

Antes de medir, el equipo de prueba comparaba recuentos para confirmar conectividad y carga. Si los contadores no coincidían, reducía la tasa. El objetivo era impedir que una saturación con pérdidas se publicara como si sólo midiera demora.

Texto, gráfica e histograma cumplían funciones distintas. La media escondía colas largas; el máximo no mostraba frecuencia. RFC 3393 y RFC 5481 explicaron más tarde que diversas fórmulas de variación responden a preguntas distintas aunque usen segundos.

Preparar no era medir

Cada ensayo tenía fases: estabilizar PNNI cuando correspondía, resolver la dirección mediante ATMARP conforme a RFC 2225, aplicar tráfico, esperar paquetes residuales y dejar que el sistema se estabilizara de nuevo. Cada fase cerraba una ambigüedad.

La resolución de dirección demostraba que la prueba podía comenzar, no que la demora fuera buena. Esperar al routing reducía transitorios, no certificaba el control plane completo. Separar paquetes tardíos evitaba contaminar el siguiente ensayo, no los convertía en éxito.

La carga debía aplicarse al menos 60 segundos. Si la varianza era alta, la recomendación subía a 300. Un periodo mayor no garantizaba representatividad; reconocía que una ventana corta podía engañar.

RFC 1242 y RFC 2544 habían separado términos de procedimientos en BMWG. RFC 2761 nombró las métricas ATM; RFC 3116 dijo cómo obtenerlas. Un nombre estable sin método estable no producía comparación.

El total no localizaba la causa

La metodología permitía agrupar varios equipos como un sistema bajo prueba. Eso daba una observación extremo a extremo, pero podía ocultar asimetrías o la demora introducida por aparatos intermedios. RFC 3116 lo advirtió expresamente.

Un par de timestamps atribuye tiempo a una frontera declarada. No identifica por sí solo la cola interna, el scheduler o el componente responsable. Dos sistemas con igual total podían repartirlo de modo diferente. Dos totales distintos podían proceder de configuraciones que nunca fueron comparables.

El documento no publicó rankings ni mediciones de marcas. Convertir la metodología en una historia de vencedores añadiría hechos que las fuentes no contienen.

El resultado era una custodia compartida

El generador poseía el estímulo. El reloj sostenía la referencia. El hardware de captura marcaba los eventos. El contador conservaba la época. El SUT reenviaba celdas en una configuración precisa. El informe reconstruía y agregaba. El lector decidía si los denominadores coincidían.

Si se elimina uno de esos eslabones, el número sigue pareciendo válido. Diez nanosegundos de resolución no son diez nanosegundos de exactitud. Un histograma no es un SLA. La demora de una celda no es latencia de aplicación. Una RFC metodológica no prueba que alguien la haya seguido.

La aportación de RFC 3116 fue mantener el aparato unido al dato. La gráfica sólo podía compararse si llevaba consigo reloj, rollover y carga.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3116.txt
  2. https://www.rfc-editor.org/info/rfc3116
  3. https://datatracker.ietf.org/doc/rfc3116/
  4. https://www.rfc-editor.org/rfc/rfc2761.txt
  5. https://www.rfc-editor.org/rfc/rfc2544.txt
  6. https://www.rfc-editor.org/rfc/rfc1242.txt
  7. https://www.rfc-editor.org/rfc/rfc2679.txt
  8. https://www.rfc-editor.org/rfc/rfc7679.txt
  9. https://www.rfc-editor.org/rfc/rfc2330.txt
  10. https://www.rfc-editor.org/rfc/rfc3393.txt
  11. https://www.rfc-editor.org/rfc/rfc5481.txt
  12. https://www.rfc-editor.org/rfc/rfc2225.txt