Resumen

  • RFC 5136 sostiene que “capacidad” carece de precisión sin especificar la capa en la que se cuentan los bits.
  • NomCap(L) es el máximo físico teórico y solo funciona como límite superior de las cantidades IP.
  • Los bits IP se cuentan en paquetes correctamente recibidos en destino durante un comienzo T y un intervalo I declarados.
  • Un fragmento válido puede contar para la capa IP aunque no produzca un objeto útil para la aplicación.
  • Type P identifica los paquetes observados porque colas, marcas, ACL, rutas y balanceo pueden tratarlos de forma diferente.
  • Uso es tráfico real recibido; utilización es la fracción entre ese uso y una capacidad igualmente calificada.
  • La capacidad disponible de un trayecto es el menor margen disponible de sus enlaces, no el mayor número de su inventario.
  • El enlace estrecho tiene la menor capacidad; el apretado, la menor capacidad disponible. Pueden ser enlaces distintos.
  • La disponibilidad es volátil y una serie mal muestreada puede repetir el mismo sesgo en lugar de corregirlo.
  • Los duplicados consumen recursos y pueden contar en IP sin aumentar los datos únicos que recibe el usuario.
  • La Bulk Transfer Capacity mide datos únicos mediante un transporte sensible a la congestión y no equivale a capacidad IP.
  • Una decisión responsable separa posibilidad física, observación IP, margen actual, derecho contractual y resultado final.

Dos mínimos que responden preguntas diferentes

Pensemos en un trayecto con varios enlaces. Uno es más lento pero está casi vacío. Otro tiene mayor capacidad, aunque soporta tráfico competidor y deja poco margen. Si solo se mira la velocidad nominal, el primer enlace parece el candidato obvio a cuello de botella. Si se pregunta qué capacidad queda ahora, el segundo puede ser el límite real.

RFC 5136 da nombres a ambos casos. La capacidad IP del trayecto es el mínimo de las capacidades IP de sus enlaces; la literatura llama estrecho al enlace que aporta ese mínimo. La capacidad disponible del trayecto es el mínimo de los márgenes disponibles; el enlace que lo aporta es el apretado. No hay obligación de que coincidan.

Esta diferencia evita una mala inversión frecuente. Ampliar el enlace estrecho puede elevar el techo del trayecto y, sin embargo, no mover el límite operativo si el enlace apretado sigue congestionado. Del mismo modo, redistribuir tráfico puede mejorar la capacidad disponible sin cambiar ningún puerto. “Añadimos capacidad” necesita decir cuál de esas realidades cambió.

La disciplina comienza antes de los mínimos. Cada valor se refiere a una capa, una población de paquetes y una ventana. Sin esa identidad, ni siquiera sabemos si dos cifras pertenecen al mismo objeto de medición.

El número de la interfaz es una posibilidad, no una entrega

La capacidad física nominal NomCap(L) representa la cantidad teórica máxima que un enlace puede soportar. RFC 5136 la separa expresamente de la capacidad IP. En general es estable, aunque el documento admite medios cuya configuración puede variar, como la activación dinámica de transpondedores.

Su papel es ofrecer un límite superior. No determina las definiciones IP posteriores. La codificación del medio, el entramado, los errores, la longitud de paquetes y el procesamiento del equipo pueden reducir lo que llega correctamente a IP. Una interfaz negociada a una velocidad no prueba el ritmo que un flujo específico puede usar.

La prueba física sigue siendo valiosa. Permite auditar inventario, negociación y compatibilidad. Lo que no puede hacer es reservar el recurso, describir la competencia, elegir una ruta o garantizar el resultado. Cuando una pantalla reutiliza la misma cifra como capacidad instalada, capacidad libre y rendimiento del cliente, ha borrado tres fronteras.

El error institucional es premiar al dueño de la primera cifra con autoridad sobre las siguientes. El equipo de activos puede saber qué se instaló. El equipo de red puede medir un comportamiento IP. El contrato define un compromiso. La aplicación revela si terminó a tiempo. Son recibos complementarios, no sustitutos.

Qué entra en el contador IP

RFC 5136 define los bits IP como ocho veces los octetos desde el primer octeto de la cabecera IP hasta el último de la carga, en paquetes recibidos correctamente por D entre T y T+I. Por eso el resultado debe conservar destino, comienzo y duración.

Los datos dañados en una capa inferior que no pueden pasar a IP no cuentan. Tampoco una cabecera IP inválida. En cambio, no se exige que la cabecera de transporte o la aplicación sean válidas. Los fragmentos IP procesables cuentan porque consumieron la capacidad del enlace, incluso si nunca se forma una unidad útil completa.

La diferencia importa al comparar con una experiencia de usuario. Cabeceras, retransmisiones, fragmentos y duplicados son trabajo real para el trayecto. Los datos únicos entregados son otra cantidad. Una métrica IP no falla al contarlos; falla la interpretación que los presenta como resultado de la aplicación.

Los límites temporales añaden una sutileza. Si el comienzo o fin corta un paquete, la porción parcial se excluye. En ventanas pequeñas, esa decisión puede sesgar el promedio. Sin T e I, un auditor no puede determinar cuánto importa ni reproducir la observación.

Type P: la población detrás del promedio

Una medición debe indicar qué paquetes representa. Type P puede ser un agregado amplio o una definición estrecha. Marcas de servicio, listas de control, políticas de encaminamiento, opciones IP, colas y balanceadores pueden hacer que dos poblaciones entre los mismos extremos sigan tratamientos o rutas diferentes.

Un proveedor puede preferir una población general para entender el recurso. Un usuario puede preferir paquetes que se parezcan a su aplicación. Ambos enfoques son legítimos si se nombran. El resultado de una sonda privilegiada no se hereda automáticamente por el tráfico ordinario. Y el resultado de una aplicación concreta no describe toda la red.

El tráfico con el que comparte el enlace también forma parte del contexto. Un flujo de prueba ejecutado cuando otra clase está inactiva no descubre una propiedad eterna. Si cambian la mezcla, la política o la ruta, cambia el objeto operativo aunque la etiqueta física permanezca igual.

La longitud del paquete altera la sobrecarga de capas inferiores. La compresión puede enviar menos bits físicos, mientras que el contador IP usa el tamaño inflado. La comparación es posible, pero requiere una transformación explícita entre capas.

Uso, utilización y margen

C(L,T,I) expresa el máximo de bits IP Type P transmitidos por S y correctamente recibidos por D en el enlace durante la ventana, dividido por I. Puede variar según la capacidad de procesamiento del dispositivo y el tipo de tráfico. La capacidad del trayecto toma el mínimo de los enlaces.

Used(L,T,I) es el tráfico IP efectivamente recibido desde cualquier fuente. No es un máximo. La utilización divide uso entre capacidad. Por ello, un porcentaje aislado es peligroso: hace falta saber qué capacidad actúa como denominador y si ambos valores comparten capa y ventana.

La capacidad disponible multiplica la capacidad por el complemento de la utilización. En el trayecto vuelve a aplicarse un mínimo. La operación parece sencilla, pero el sentido depende de todas las calificaciones previas. Un valor calculado con inventario físico y tráfico IP mezcla capas; uno calculado con ventanas distintas mezcla tiempos.

La disponibilidad cambia más rápido que la capacidad. Una medición puntual puede ser correcta y, a la vez, no representar la hora siguiente. Una serie mejora la caracterización solo si su diseño evita el sesgo.

Cuando la periodicidad engaña

El tráfico de Internet varía en muchas escalas. RFC 5136 advierte que una frecuencia de muestreo múltiplo de un fenómeno subyacente puede caer siempre en la misma fase. Una sonda horaria puede coincidir siempre con la pausa de un proceso o con su máximo.

Más observaciones no corrigen automáticamente esa coincidencia. Hay que preservar programación, variación deliberada, ejecuciones perdidas, relojes, cambios de ruta y eventos de mantenimiento. La serie debe permitir una inferencia, no solo llenar una gráfica.

También debe declararse la caducidad operativa. La mejor medición de ayer sigue siendo evidencia de ayer. Si se modifica una cola, una política, el camino o el software del extremo, la decisión actual necesita una nueva prueba o una justificación explícita de continuidad.

El duplicado y la ilusión de trabajo útil

En la forma más general de la definición, si un equipo duplica un paquete y ambos ejemplares llegan correctamente, ambos cuentan. La red realizó trabajo dos veces. El receptor interesado en información única quizá quiera contar una sola copia. Type P o una regla adicional debe expresar esa diferencia.

Esto convierte una anomalía en una lección de gobernanza. Un número más alto puede significar mayor trabajo y menor eficiencia. Si el cuadro de mando solo conserva la tasa agregada, desaparece la evidencia de duplicación que permitiría explicar la discrepancia con la aplicación.

La Bulk Transfer Capacity de RFC 3148 se sitúa precisamente en otra perspectiva. Cuenta datos únicos de una conexión de transporte sensible a congestión y excluye cabeceras y retransmisiones. Pérdida, latencia, reordenamiento y algoritmo de recuperación modifican el resultado. No corresponde a las cantidades IP de RFC 5136.

RFC 9097 y otros trabajos posteriores concretan métodos para capacidad IP. RFC 9946 describe una prueba UDP controlada. Esa precisión mejora la trazabilidad del test. No concede capacidad al abonado, no interpreta el SLA y no demuestra que una aplicación haya acabado.

El expediente mínimo para una afirmación de capacidad

Primero se registra el medio, la negociación y NomCap(L). Después, extremos, trayecto y enlaces. Luego la capa, Type P, tamaños, marcas, criterio de recepción y tratamiento de errores, fragmentos y duplicados. La identidad temporal incluye T, I, reloj y calendario de muestreo.

Con esa base pueden evaluarse la capacidad por enlace, el mínimo del trayecto, el uso, el denominador de utilización, la disponibilidad y el enlace apretado. Estados de rutas, colas y balanceo deben quedar asociados a la observación. Una prueba activa debe registrar su propia carga y sus límites de seguridad.

El compromiso comercial se incorpora por separado: tasa contratada, perfil de ráfaga, percentil, exclusiones y autoridad que decide. La aplicación aporta datos únicos, reintentos, integridad, plazo y resultado visible. Ningún campo anterior debe rellenar estos recibos por inferencia.

La discrepancia entre capas es útil. Permite distinguir un problema físico, una ruta estrecha, competencia temporal, control de transporte o fallo de aplicación. La organización aprende más de una cadena que no coincide que de una cifra única cuidadosamente verde.

Coordinación delgada, prueba local completa

RFC 5136 ofrece un lenguaje común. Esa coordinación es potente porque mantiene pequeño su ámbito: define cantidades para que distintas partes puedan compararlas. No instala capacidad, no reserva recursos, no autoriza carga de prueba y no decide quién tiene derecho al resultado.

La realidad local sigue necesitando código, configuración, medición y responsabilidad. Cada transición debe conservar procedencia. La posibilidad física no se convierte por decreto en margen presente; el margen no se convierte en entrega; la entrega no se convierte en resultado satisfactorio sin prueba del receptor.

La dirección debe impedir que el equipo que controla un contador se convierta también en juez de todas las capas. Inventario, medición, operaciones, contrato y aplicación deben emitir recibos separados. RFC 5136 ocupa un lugar esencial en esa cadena, pero no pretende sustituirla.

El enlace más lento y el enlace realmente limitante pueden ser distintos. Esa pequeña distinción basta para recordar que el número más visible rara vez posee toda la verdad.

Fuentes

  1. RFC 5136, HTML
  2. RFC 5136, texto plano
  3. Registro de RFC Editor
  4. Registro de IETF Datatracker
  5. Historial de RFC 5136
  6. Búsqueda de erratas
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary