Resumen

  • RFC 1077 fue una agenda de investigación informativa, no la especificación de una red gigabit desplegada. Enumeró los sistemas necesarios para convertir capacidad óptica en acceso útil.
  • Su inversión principal fue que los enlaces troncales crecían más deprisa que los elementos de conmutación. La escasez podía desplazarse del medio a la electrónica, el trabajo por paquete, la memoria y el host.
  • RFC posteriores separaron el rendimiento de un dispositivo, la promesa de un servicio y la observación de un camino. Ninguno de esos planos equivale a la velocidad nominal de la línea.

El vidrio no terminaba el trabajo

RFC 1077 partió de una abundancia inesperada. La fibra ya instalada permitía pensar en agregados de gigabits por segundo y en ancho de banda bruto próximo a terabits. Pero el grupo no convirtió esa cifra en una promesa. Preguntó cómo servir varios gigabits a un usuario y, a la vez, varios megabits a enormes poblaciones mediante agregación asequible.

La diferencia es la arquitectura. La capacidad bruta describe una oportunidad de transmisión. El servicio describe lo que una aplicación obtiene al cruzar equipos, políticas, cargas competidoras y puntos de acceso.

El Gigabit Working Group, reunido a petición de DARPA, produjo un informe para orientar investigación. Las demostraciones propuestas —troncal gigabit, redes interconectadas con gestión y una arquitectura de acceso— no eran prueba de despliegue. El propio texto aclara que sus ejemplos ilustran problemas y no prescriben una tecnología concreta.

Su valor histórico está precisamente en ese inventario abierto. Antes de elegir la solución, distinguió las capas que el número de la fibra ocultaba.

La velocidad trasladó la restricción

Las redes de área extensa anteriores se diseñaban como si el ancho de banda fuera el recurso escaso. El conmutador debía aprovechar con cuidado una línea cara. RFC 1077 observó que la velocidad de las troncales empezaba a crecer más deprisa que la de los elementos de conmutación.

La fibra llevaba bits; la electrónica seguía decidiendo destinos, aplicando control, almacenando y procesando. La conmutación por paquetes tradicional exigía trabajo por paquete. Si aumentaban los bits por segundo, pero no los paquetes procesables por segundo, el equipo podía saturarse con tramas pequeñas sin llenar la capacidad nominal en bits.

Después aparecía el host. El informe anticipó que su procesamiento de paquetes podía impedir que una aplicación recibiera un flujo de alta tasa aunque las troncales moviesen un gran agregado. Copias de memoria, protocolos, periféricos e interfaz de red eran parte del recorrido. La línea no depositaba datos directamente en la aplicación.

No desaparecía la escasez: cambiaba de propietario y de unidad. Mejorar el medio revelaba la siguiente limitación del sistema.

Un total no describía la demanda

El grupo distinguió unos pocos dispositivos con necesidades individuales enormes y millones de usuarios moderados cuyo tráfico sumaba la misma escala. Sus ráfagas, simultaneidad y posibilidades de control eran diferentes.

También separó rendimiento, retardo, dispersión del retardo, fiabilidad y entrega ordenada. La transferencia masiva quiere volumen. La simulación interactiva quiere respuesta. Voz y vídeo necesitan regularidad. El control de red ocupa poco, pero puede ser crítico.

RFC 1077 examinó comunicaciones orientadas a conexión, sin conexión y flujos síncronos; para estos últimos describió una reserva capaz de establecer una cantidad estable de ancho de banda. Añadió tipo de servicio, política, equidad y reservas anticipadas.

Así surgía otra autoridad. La aplicación debía declarar qué servicio necesitaba y la red decidir cómo asignarlo. Sin embargo, una aplicación rara vez sabía traducir «rápido» a tasa, demora, pérdidas admisibles y duración. La capacidad física no podía resolver por sí sola esa negociación.

Gestionar era parte de entregar

RFC 1077 llamó a la próxima red, ante todo, una arquitectura de gestión. A medida que enlace, procesador y memoria resolvían problemas simples, los sistemas mayores acumulaban interacciones de rendimiento, fiabilidad y seguridad.

La gestión incluía contabilidad, seguridad, observación del rendimiento, aislamiento de fallos y configuración. La contabilidad podía registrar ancho asignado, paquetes o puertos para aplicar una tarifa o política. Ese registro decía qué se concedió o cobró; no decía qué recibió el usuario.

La observación del rendimiento era otra superficie. El informe quería evolucionar desde la queja y la reacción hacia el diagnóstico preventivo y la asignación dinámica. También entendió que el volumen de datos de gestión exigiría umbrales, filtros y alertas para no ahogar al operador sin perder el detalle de diagnóstico.

Más velocidad creaba más estado que gobernar. La gestión no era una consola añadida al final, sino uno de los sistemas que convertían capacidad en continuidad.

La capacidad del equipo necesita condiciones

RFC 1242 definió después el throughput de un dispositivo de interconexión como la máxima tasa ofrecida a la que no descarta ninguna trama. No es el bit rate teórico del medio.

Tamaño de trama, dirección, enrutamiento o puente, comprobaciones y tareas de control cambian el resultado. La misma RFC separa latencia, pérdida, sobrecarga, trabajo auxiliar y ráfagas. Un equipo competente con tramas grandes y constantes puede comportarse de otro modo con paquetes pequeños o actualizaciones de rutas.

RFC 2544 fijó procedimientos comparables: contraponer límite teórico y throughput medido, medir latencia a la tasa establecida y registrar pérdida para distintas cargas y tamaños. La tabla completa debía acompañar cualquier cifra seleccionada para publicidad.

Esas pruebas caracterizan un dispositivo aislado y configurado. No demuestran sin más un camino de producción, el tiempo que tarda una aplicación ni un nivel contractual.

Una reserva representa un compromiso condicionado

RFC 1633 rechazó más tarde la idea de que una fibra abundante volviera inútil la gestión explícita de recursos. El ancho bruto puede parecer barato sin estar disponible como servicio barato, ubicuo y libre de congestión.

Integrated Services recurrió a reserva y control de admisión. Clasificador, planificador y decisión de admisión escogían el tratamiento de cada flujo. Eran mecanismos de control y compromiso, no propiedades del vidrio ni observaciones posteriores.

RFC 2212 especificó una promesa fuerte: con parámetros de tráfico respetados y elementos conformes, el servicio garantizado podía acotar el retardo de cola y evitar descartes por desbordamiento. El retardo fijo del camino seguía aparte. La instalación podía usar RSVP, configuración manual o un protocolo de gestión.

Aceptar una reserva demuestra que un sistema asumió un compromiso bajo un modelo. No demuestra por sí solo que la ruta permaneció estable, que todos los elementos siguieron conformes o que el receptor observó el resultado.

El resultado del camino requería observadores

RFC 2679 definió el retardo unidireccional con origen, destino, tipo de paquete y tiempo. Separó una observación individual, una muestra y sus estadísticas. Sincronización de relojes, incertidumbre y distinción entre un paquete muy tardío y uno perdido limitan la inferencia.

RFC 3393 definió la variación de retardo como la diferencia entre retardos unidireccionales de paquetes seleccionados. Sirve para dimensionar búferes de reproducción y estudiar colas, pero no es capacidad, retardo medio ni un valor universal de «jitter».

El problema de RFC 1077 puede ordenarse en cuatro planos:

  1. capacidad bruta del medio bajo supuestos definidos;
  2. capacidad de procesamiento del equipo y del host bajo una carga declarada;
  3. trato de servicio que el control asigna o promete bajo condiciones;
  4. rendimiento entregado que observadores concretos miden en una ruta y periodo.

Un plano limita a los siguientes, pero su evidencia no los sustituye. La fibra no es un benchmark; el benchmark no es una reserva; la reserva no es una llegada observada.

La cifra sin apellido es la más engañosa

RFC 1077 no terminó Internet gigabit. Conservó una disciplina más útil: el componente más rápido no representa el servicio completo. Una abundancia técnica puede descubrir una escasez de procesamiento, coordinación o evidencia.

Ante cualquier promesa de velocidad hay que preguntar quién produjo el número, en qué capa, con qué dirección, tamaño, carga, camino y ventana temporal. ¿Es capacidad, aptitud, compromiso o resultado?

La fibra era rápida. Entregar servicio seguía exigiendo un sistema entero.

Fuentes y límites probatorios

RFC 1077 aporta la agenda de 1988; RFC 1242 y RFC 2544, la frontera de capacidad de dispositivo; RFC 1633 y RFC 2212, la de compromiso de servicio; RFC 2679 y RFC 3393, la de observación del camino. Prueban modelos y requisitos publicados, no despliegue universal, rendimiento actual ni una descendencia directa desde RFC 1077.