Resumen

  • RFC 3133 definió tasas de octetos y tramas entregados para un solo sentido de una conexión virtual Frame Relay, manteniendo separadas la carga comprometida y la excedente.
  • El propio RFC advirtió que perder una confirmación pequeña podía causar muchas retransmisiones: la tasa seguía siendo correcta dentro de su ámbito, pero no probaba que la aplicación funcionara bien.

El dato más pequeño gobernaba el trabajo mayor

En una transferencia, las tramas grandes suelen viajar en un sentido. En el otro vuelve una confirmación breve. Si esa confirmación se pierde después de que casi todos los datos hayan cruzado la red, el cociente de octetos entregados apenas cambia. El cociente de tramas también puede conservar un aspecto excelente. Para el emisor, en cambio, falta la evidencia que le permite avanzar y retirar trabajo pendiente.

RFC 3133 convirtió esta escena en una advertencia metodológica. Al definir Data Delivery Ratio y Frame Delivery Ratio, explicó que esas magnitudes podían no representar la eficacia de entrega para una aplicación. Una pequeña trama de acuse perdida podía obligar a retransmitir un gran número de tramas de datos. El usuario experimentaría un servicio pobre mientras el indicador seguía mostrando un buen valor.

No había contradicción matemática. La fórmula respondía a una pregunta acotada: qué proporción de una población declarada llegó entre dos puntos. La aplicación dependía de la relación causal entre algunos elementos de esa población. Contar unidades no preservaba necesariamente la autoridad que una unidad ejercía sobre las demás.

La velocidad del puerto no era el contrato

El documento empezaba por ordenar términos que la conversación comercial podía mezclar. El canal de acceso era la interfaz física por la que el usuario introducía tráfico. Su Access Rate marcaba el máximo ritmo de inyección. Eso no significaba que toda esa capacidad estuviera comprometida por el servicio.

El Committed Information Rate, CIR, era la velocidad de transporte que la red mantendría entre las ubicaciones contratadas cuando se presentaran datos. Bc delimitaba la cantidad comprometida durante el intervalo Tc. Be representaba la ráfaga no comprometida que la red podía intentar entregar con menor probabilidad.

Tc tampoco era una casilla periódica del reloj. RFC 3133 lo describió como una ventana deslizante activada por la llegada de datos y calculada como Bc dividido por CIR. Para saber si una trama pertenecía al compromiso o al exceso había que conservar el momento y el patrón de la oferta, no solo la etiqueta del puerto.

El bit Discard Eligible, DE, expresaba una preferencia de descarte durante congestión. No era el recibo de un descarte. RFC 3133 separó las tramas discardable de las discarded: unas podían ser candidatas y sobrevivir; otras podían caer por políticas por circuito, por criterios de IP o puertos, o por errores de formato e integridad.

Esa diferencia reconstruía la autoridad. El contrato definía qué se prometía. La clasificación decidía qué quedaba expuesto. El dispositivo ejecutaba o no el descarte. El contador observaba el resultado. Ninguno de esos pasos podía sustituir a los demás.

El porcentaje tenía dirección y domicilio

RFC 3133 heredó de RFC 1242 el formato disciplinado para definir términos. También aclaró que los documentos de terminología nombraban las métricas, mientras que los de metodología especificaban procedimientos para obtenerlas. Publicar una fórmula no equivalía a haber realizado una prueba.

DDR comparaba octetos útiles entregados con octetos útiles ofrecidos. Excluía el campo de dirección y el FCS. La tasa de entrega de tramas comparaba recepciones satisfactorias con intentos de transmisión. Ambas medidas pertenecían a un sentido de una única conexión virtual.

Por ello, una conexión dúplex mantenía dos conjuntos independientes. La cifra del trayecto de datos no describía el retorno. Un resultado de un DLCI no describía todos los circuitos asociados a un puerto. Y una observación entre dos fronteras no incluía automáticamente lo sucedido antes de entrar ni después de salir.

El RFC permitía además separar la carga comprometida de la excedente. DDR_c y su equivalente de tramas representaban el tráfico dentro del CIR. DDR_e describía el exceso. La cifra total podía ser exacta y, a la vez, esconder que el servicio incumplía precisamente la población que debía garantizar.

Antes de interpretar una tasa había que preguntar: ¿qué circuito, qué sentido, qué intervalo, qué clase de carga, qué tamaño de cabecera, qué puntos de medición? Sin esa ficha, el decimal era reproducible solo en apariencia.

Los bytes no conocían la función del acuse

Una razón de octetos concede más peso a las tramas grandes. Una razón de tramas trata como una unidad tanto al dato voluminoso como a la confirmación diminuta. Ninguna conserva por sí sola la semántica de control.

Un acuse puede abrir espacio en una ventana, confirmar el progreso acumulado, evitar un temporizador o permitir que el emisor libere estado. Su influencia se mide por la transición que autoriza, no por su longitud. Perderlo puede multiplicar el trabajo; recibirlo puede retirar una cola entera.

Sería fácil inventar una prueba con 999 entregas de mil y anunciar 99,9 %. Pero RFC 3133 no documentó ese experimento. Su ejemplo era deliberadamente general. No ofrecía un factor de amplificación, un producto o una aplicación concreta. Por eso, el artículo tampoco puede convertir la posibilidad en una cifra histórica.

Tampoco toda pérdida de acuse produce una catástrofe. Otra confirmación acumulativa podría llegar; el temporizador, la ventana o la implementación podrían limitar el daño. El valor del ejemplo está en romper la equivalencia lógica: una buena tasa no basta para demostrar un buen resultado.

El promedio de demora dejaba fuera lo que no llegó

Frame Transfer Delay tenía sus propios bordes. El RFC definía la salida de la trama en un punto y su entrada en otro. El promedio se calculaba sobre las tramas recibidas. Las enviadas durante el intervalo que no aparecían en el destino quedaban fuera.

La decisión es coherente con la definición, pero impide leer la demora sin la pérdida. Una media baja puede corresponder al conjunto superviviente, mientras las ausentes concentran el peor efecto. El número mejora si el observador olvida preguntar quién no entró en la muestra.

Frame Transfer Delay Variation usaba la diferencia entre el máximo y el mínimo observados. RFC 3133 relacionaba una variación grande con el cálculo de ida y vuelta de TCP y con su rendimiento, y señalaba que una demora excesiva podía dañar aplicaciones como la voz sobre IP. Eran límites técnicos, no resultados medidos en una red real.

Descartar un error no era lo mismo que castigar exceso

El RFC enumeraba varias causas de descarte por error: longitud inválida, alineación incorrecta, DLCI desconocido, secuencia de aborto, delimitación defectuosa o FCS fallido. Bloquear una trama corrupta podía ser mejor que propagarla y obligar a niveles superiores a trabajar con información dañada.

Así, un solo contador de descartes podía reunir acciones con motivos opuestos. La policía de tráfico protegía el contrato. La preferencia DE gestionaba congestión. La validación de FCS protegía integridad. Todas podían provocar una retransmisión, pero no señalaban la misma avería ni al mismo responsable.

La investigación debía retener la genealogía del evento. ¿La trama fue observada en el ingreso? ¿Se clasificó como comprometida o excedente? ¿Era elegible? ¿Qué regla la descartó? ¿Tenía un error? ¿Faltó después una confirmación en el sentido inverso? ¿La recuperación fue inmediata o esperó un vencimiento? El porcentaje final no contenía esas respuestas.

Un vocabulario, no una prueba de campo

RFC 3133 apareció en junio de 2001 como documento Informational del Benchmarking Methodology Working Group. Extendía RFC 1242, RFC 1944 y RFC 2285 y reunía términos del Frame Relay Forum y de la MIB de servicio Frame Relay.

No comparaba equipos ni certificaba a un operador. No demostraba que los contadores estuvieran disponibles, que un contrato los aplicara con fidelidad o que los usuarios obtuvieran una experiencia determinada. El último borrador del grupo de trabajo documenta cómo se formó el texto, no cómo se desplegó.

RFC 1944, RFC 2544 y RFC 2889 ocupaban el terreno de la metodología. RFC 2761 aportaba contexto ATM para el interfuncionamiento. RFC 2954 definía objetos gestionados. RFC 6349 llegaría después con un marco para pruebas de rendimiento TCP. Son vecinos documentales, no recibos de una implementación de RFC 3133.

Su contribución duradera fue definir una frontera honesta. La red podía declarar con precisión que había entregado una proporción de octetos o tramas. Para declarar que el servicio había satisfecho a la aplicación, debía presentar otra cadena de pruebas.

Tres registros para una sola historia

El primer registro debería contener el canal, el DLCI, el sentido, el intervalo, CIR, Bc, Be y Tc; las tramas y octetos ofrecidos y entregados; la separación entre compromiso y exceso; DE, policía, errores, descartes, FECN/BECN y puntos de observación.

El segundo debería reconstruir el transporte: qué confirmación faltó, qué estado dependía de ella, cuándo venció el temporizador, qué se retransmitió y cómo terminó la recuperación. El tercero pertenecía a la aplicación: operación, criterio de finalización, duración, reintentos, estado final y consecuencia visible.

Ninguno de los registros superiores se puede completar copiando el porcentaje inferior. DDR es evidencia sobre octetos útiles en su ámbito. Una tasa de tramas es evidencia sobre tramas. No son pruebas de finalización, cumplimiento contractual o satisfacción humana.

Frame Relay quedó atrás como tecnología dominante, pero la tentación permanece. Cada plataforma elige una señal barata de agregar y la presenta como salud. La defensa que dejó RFC 3133 es simple y exigente: conservar la cifra, conservar su jurisdicción y no permitir que hable por el sistema que no midió.

Fuentes

  1. https://www.rfc-editor.org/rfc/rfc3133.txt
  2. https://www.rfc-editor.org/info/rfc3133
  3. https://www.rfc-editor.org/rfc/rfc3133.html
  4. https://www.rfc-editor.org/rfc/rfc1242.html
  5. https://www.rfc-editor.org/rfc/rfc1944.html
  6. https://www.rfc-editor.org/rfc/rfc2285.html
  7. https://www.rfc-editor.org/rfc/rfc2544.html
  8. https://www.rfc-editor.org/rfc/rfc2761.html
  9. https://www.rfc-editor.org/rfc/rfc2889.html
  10. https://www.rfc-editor.org/rfc/rfc2954.html
  11. https://www.rfc-editor.org/rfc/rfc6349.html
  12. https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-fr-term-06