Resumen

  • El informe BBN 7080 de Craig Partridge sostuvo en 1989 que la velocidad de un gigabit no imponía por sí sola una arquitectura nueva. Había que localizar primero la restricción en paquetes por segundo, instrucciones, movimiento de datos, memoria en vuelo o control.
  • La conclusión dependía de supuestos visibles: paquetes medios mayores, procesadores de 60–70 MIPS, caminos de 64 bits y memoria suficiente. La propagación no mejoraba con el enlace, por lo que crecían el inventario de datos y el coste de aprender la capacidad.
  • El MultiGigabit Router de 1998, obra de un amplio equipo de BBN, aportó una prueba posterior con backplane de 50 Gb/s y hasta 32 millones de paquetes por segundo. El documento conservó, además, lo que aún era estimación o trabajo incompleto.

La magnitud había sustituido al mecanismo

El informe How Slow Is One Gigabit Per Second?, fechado el 5 de junio de 1989 y archivado en las actas de IETF 14, no comenzó con un colapso observado. Comenzó con una convicción: las arquitecturas de datagramas no podrían escalar a velocidades tan altas. El umbral de fallo no estaba bien definido; el gigabit era, sencillamente, bastante grande como para resultar persuasivo.

Partridge buscó el punto donde la intuición pudiera quedar desmentida. Su tesis no era que el gigabit fuese trivial, ni que una arquitectura jamás debiera cambiar. Era más precisa: la velocidad aislada no obligaba a elegir entre datagramas y circuitos virtuales. Si ambos podían alcanzar el objetivo, la preferencia necesitaba argumentos de servicio, control o coste; no podía presentarse como necesidad física.

Ese gesto convierte el artículo histórico en una cuestión contemporánea. Un número no es una causa. Para decidir, hay que encontrar el recurso consumido por unidad de trabajo.

Cada paquete reducía el tiempo disponible

El modelo partía de dos previsiones. En las redes gigabit, el paquete medio sería al menos tan grande como en la Internet de entonces, por el aumento del tráfico masivo y de las MTU. Y componentes ya presentes en producción de prueba permitían proyectar un procesador RISC de 60 a 70 MIPS y caminos de datos de 64 bits para los primeros años noventa.

En el router, el coste dominante era una decisión por paquete. Los 6.000–10.000 paquetes por segundo esperados entre unas pocas Ethernet se convirtieron, mediante una extrapolación lineal, en 600.000–1.000.000 al llegar al gigabit. Sobre una CPU de 60 MIPS, cada paquete disponía de 60–100 instrucciones y de 1–1,6 microsegundos antes del siguiente.

Eso no garantizaba el éxito, pero identificaba el examen. Un circuito podía repartir el coste de su establecimiento entre muchos paquetes. El IP básico de la época necesitaba en torno a 100–150 instrucciones en procesadores de 32 bits, además de controladores. Operaciones de 64 bits, canalización y ayuda especializada podían recortar el presupuesto. Un tráfico de paquetes muy pequeños podía consumirlo antes. El mismo gigabit podía significar medio millón o varios millones de decisiones.

El cuello del host estaba en tocar los datos

Un router podía limitarse en gran parte a la cabecera; el host entregaba los bytes a una aplicación. Partridge separó protocolo, sistema operativo y procesamiento de datos. A partir del análisis de TCP de Clark, Jacobson, Romkey y Salwen, formuló una carga ilustrativa de unas mil instrucciones fijas y otra proporcional a la longitud dividida por el ancho de palabra.

Su gráfico daba a la longitud media el papel decisivo. Con el modelo de 60 MIPS, cerca de 3 KB por paquete permitían ocupar el gigabit. A 512 bytes, el host rozaba un cuarto del enlace; a 100 bytes, unos 50 Mb/s. Son cifras históricas, no predicciones para una máquina actual. La lección permanece: ancho de banda, tasa de paquetes y tasa de acceso a memoria son contratos distintos.

La RFC 1071, firmada por Bob Braden, David Borman y Partridge, propuso combinar la copia de memoria con el cálculo de la suma de comprobación para leer los bytes una sola vez. No era solo una optimización aritmética; evitaba una segunda travesía de datos. La RFC 4297 resumió después estudios en los que tocar datos dominaba los mensajes largos y citó una medición antigua sobre Sun-3/60: 64% de la sobrecarga medida correspondía a operaciones sobre datos y 48% a copia. Esos porcentajes pertenecen al estudio de Clark y no describen sistemas modernos. Sí recuerdan qué recibo debe conservarse: los cruces reales de memoria.

Más velocidad dejó más bytes atrapados en la distancia

La fibra no acortó el recorrido. A un gigabit, el mismo retardo encerraba más información entre emisor y receptor. Para una distancia extrema, el informe calculó unos 5,9 MB de producto ancho de banda-demora. Con un servicio de operador que implicaba al menos 120 ms de ida y vuelta, la cifra subía a 15 MB. La memoria prevista hacía esos volúmenes plausibles, aunque costosos.

Partridge distinguió esa reserva de los retardos internos. Cien elementos de conmutación, cada uno dentro del tiempo por paquete calculado, añadirían apenas 12,5–20 KB de búfer. La geografía dominaba; no cada salto rápido.

El segundo problema era el tiempo para descubrir la capacidad. Un emisor de datagramas que comenzara con ocho bytes y duplicara la oferta en cada vuelta alcanzaría el orden de un gigabit en menos de dos segundos. La conclusión era doble: el control existente no quedaba destruido, pero una espera de dos segundos podía inutilizar una aplicación corta. Cabía mejorar la información o el arranque sin declarar inválida toda la arquitectura.

El router posterior no borró sus asteriscos

En 1998, Partridge encabezó a un equipo numeroso en el artículo sobre el MultiGigabit Router. El sistema declaraba un backplane full-duplex de 50 Gb/s y hasta 32 millones de reenvíos por segundo. Aproximadamente una cuarta parte del backplane se consumía en tráfico auxiliar, dato que impedía confundir capacidad interna nominal con carga útil.

La ruta del paquete estaba diseñada para reducir movimiento. La tarjeta de entrada conservaba el cuerpo y enviaba la cabecera a un motor. El motor consultaba una copia completa de la tabla de reenvío, modificaba la cabecera y devolvía la decisión. Después, el paquete cruzaba el conmutador hacia la salida. La replicación evitaba que una tabla central se convirtiera en una consulta muchísimo más cara que el propio reenvío. Un tejido conmutado sustituyó al bus compartido, los motores quedaron separados de las interfaces, las cabeceras de enlace se normalizaron y la clasificación QoS se dividió del planificador de salida.

El artículo no simuló una culminación. Al enviarse a imprenta, todo el hardware excepto las tarjetas de interfaz había sido fabricado y probado, y la mayoría del software estaba en marcha. La latencia de siete a ocho microsegundos para 128 bytes seguía siendo una estimación construida con rendimiento real del software, observación del hardware y simulación. Esa mezcla debía acompañar el número.

El equipo sostuvo que revisar cada cabecera IP era viable a gran velocidad y que la tecnología de routers no estaba fracasando. No sostuvo que una prueba garantizara cualquier tabla, mezcla de tráfico, convergencia o generación posterior.

Una biografía de límites que se podían medir

El Internet Hall of Fame reconoce a Craig Partridge por el enrutamiento del correo mediante nombres de dominio, el anycast, aportes a la estimación RTT de TCP y el liderazgo del primer router multigigabit. Colorado State University lo presenta hoy como profesor interesado en cualquier problema que mueva bits, paquetes, bloques o archivos entre máquinas.

Su argumento de 1989 ofrece un modo de leer esa trayectoria. No empezaba por la institución o por la etiqueta de la arquitectura. Empezaba por una secuencia de afirmaciones que podían fallar. El bit rate pasaba a paquetes; el paquete, a instrucciones; la distancia, a bytes en vuelo; el prototipo, a estados separados de fabricación, medición, simulación y ausencia.

La Running-Code Primacy exige justamente esa disciplina. Quien propone transferir inversión, compatibilidad o control a una arquitectura nueva debe probar la insuficiencia de la ruta que existe. El gigabit de Partridge no necesitó otra Internet porque, al dividirlo, sus componentes todavía tenían una respuesta ejecutable. Ese resultado era válido mientras sobrevivieran sus supuestos, no un día más.

Fuentes