Spanish S3T1Where Wizards Stay Up Late The Origins of The Internet

Machine Translated by Google
DONDE SE ALOJAN LOS MAGOS

HASTA TARDE
(LOS ORÍGENES DE INTERNET)
Katie Hafner y Mateo

León
Un lanzamiento de NERD de DF Books
PIEDRA DE TOQUE
Centro Rockefeller
1230 Avenida de las Américas
Nueva York, Nueva York 10020
Visítenos en la World Wide Web: http://

www.SimonSays.com
Copyright © 1996 de Katie Hafner y Matthew Lyon
Todos los derechos reservados, incluido el derecho de reproducción total o parcial en cualquier forma.
Primera edición de Touchstone 1998

TOUCHSTONE y colofón son marcas registradas de Simon & Schuster Inc.
Incluye índice.
ISBN 0684872161
A la memoria de JCR Licklider
y a la memoria de Cary Lu
También por Katie Hafner
La casa del puente: una historia de la Alemania moderna
Cyberpunk: forajidos y piratas informáticos en la frontera informática (con John Markoff)
Los orígenes de
Internet
Katie Hafner y Matthew Lyon

UN LIBRO DE PIEDRA DE TOQUE
Publicado por Simon & Schuster
Contenido
Prólogo
1.El millón de dólares más rápido
2.Un bloque aquí, algunas piedras allá
3.La Tercera Universidad
4. Dirígete hacia abajo en los bits
5.Hazlo con Truett
6. Hackear y gritar
7.Correo electrónico
8.Un cohete en nuestras manos
Epílogo
Notas del capítulo
Bibliografía
Expresiones de gratitud
Índice
Las luces de Los Álamos donde los magos se quedan despiertos hasta tarde
(Quédate en el auto, olvídate de la puerta)

Para salvar el mundo o acabar con él, el tiempo lo dirá
—James Merrill,
"Bajo Libra: pesos y medidas",
fromDesafiando los elementos
Prólogo
septiembre de 1994
Llegaron a Boston desde lugares tan lejanos como Londres y Los Ángeles, varias docenas de hombres de
mediana edad, y se reunieron durante un fin de semana de otoño de 1994 para celebrar lo que habían hecho
veinticinco años antes. Estos eran los científicos e ingenieros que habían diseñado y construido ARPANET, la red
informática que revolucionó las comunicaciones y dio origen a Internet global. Habían trabajado en relativa oscuridad
en la década de 1960; varios de ellos eran sólo estudiantes de posgrado cuando hicieron contribuciones significativas
a la red. Otros habían sido mentores. La mayoría de ellos nunca habían obtenido mucho reconocimiento por el logro.
Bolt Beranek y Newman, una empresa informática con sede en Cambridge, habían sido su centro de gravedad,
habían empleado a muchos de ellos, habían construido y operado la red ARPA original, y luego cayeron en una
relativa oscuridad a medida que Internet crecía como una ciudad bulliciosa en torno a sus primeros orígenes.
vecindario. Ahora, un cuarto de siglo después de instalar el primer nodo de red, BBN había invitado a todos los
pioneros de ARPANET a reunirse, con la esperanza de realzar su propio perfil organizando una fastuosa celebración
para conmemorar el aniversario.
Muchos de los asistentes a la reunión no se habían visto ni habían estado en contacto durante años. Mientras
ingresaban al vestíbulo de Copley Plaza para la conferencia de prensa del viernes por la tarde que daba
inicio a la celebración, escanearon la sala en busca de rostros familiares.
Bob Taylor, director de un centro de investigación empresarial en Silicon Valley, había venido a la fiesta por los
viejos tiempos, pero también tenía la misión personal de corregir una inexactitud de larga data. Durante
años habían persistido los rumores de que ARPANET había sido construido para proteger la seguridad nacional
frente a un ataque nuclear. Era un mito que no había sido cuestionado durante el tiempo suficiente para ser
ampliamente aceptado como un hecho.
Taylor había sido el joven director de la oficina dentro de la Agencia de Proyectos de Investigación Avanzada
del Departamento de Defensa que supervisaba la investigación informática, y fue él quien inició ARPANET. El
proyecto encarnaba las intenciones más pacíficas: conectar computadoras en laboratorios científicos
de todo el país para que los investigadores pudieran compartir recursos informáticos. Taylor conocía
ARPANET y su progenie,
Internet, no tuvo nada que ver con apoyar o sobrevivir a la guerra; nunca lo tuvo. Sin embargo, se sentía
bastante solo al llevar ese conocimiento.
Últimamente, la prensa dominante había retomado el sombrío mito de un escenario de supervivencia nuclear y
lo había presentado como una verdad establecida. Cuando la revista Time cometió el error, Taylor escribió
una carta al editor, pero la revista no la publicó. El esfuerzo por dejar las cosas claras fue como perseguir el
viento; Taylor estaba empezando a sentirse como un chiflado.
Esa noche, durante la cena en el Copley, al otro lado de la habitación, Taylor vio a un hombre mayor y
corpulento con un espeso bigote. Lo reconoció inmediatamente como la única persona que podía corroborar
convincentemente su historia. Era su antiguo jefe, Charlie Herzfeld, que había sido director de ARPA cuando
Taylor trabajaba allí. Los dos hombres se habían visto por última vez años antes, antes de que a nadie le
importara cómo comenzó la red. Al ver a Herzfeld ahora, Taylor se animó. Estaba de nuevo entre las personas
que conocían la verdadera historia. Ahora arreglarían las cosas.
1
El millón de dólares más rápido
febrero de 1966
Bob Taylor solía ir al trabajo en coche, treinta minutos a través de la ondulada campiña al noreste de
Washington, cruzando el río Potomac hasta el Pentágono. Allí, por la mañana, se detenía en uno de los amplios
aparcamientos e intentaba dejar su posesión más preciada, un BMW 503, en algún lugar que pudiera
recordar. En 1966 había pocos o ningún puesto de control de seguridad en las entradas del Pentágono. Taylor
entró con su vestimenta habitual: chaqueta deportiva, corbata, camisa de manga corta con botones y pantalones
de vestir. Otras treinta mil personas pululaban diariamente por el nivel de la explanada, tanto uniformados
como muftíes, pasando por las tiendas y entrando en los laberintos del enorme edificio.
La oficina de Taylor estaba en el tercer piso, el nivel más prestigioso del Pentágono, cerca de las oficinas del
secretario de Defensa y del director de la Agencia de Proyectos de Investigación Avanzada (ARPA). Las
oficinas de los funcionarios de más alto rango del Pentágono estaban en el exterior, o anillo E. Sus suites tenían
vistas al río y a los monumentos nacionales. El jefe de Taylor, Charles Herzfeld, director de ARPA, estaba
entre los que tenían vistas, en la habitación 3E160.
El director de ARPA calificó los más altos símbolos de poder otorgados por el Departamento de Defensa (DOD),
hasta las banderas oficiales junto a su escritorio. Taylor era director de la Oficina de Técnicas de Procesamiento
de Información (IPTO), a sólo un corredor de distancia, una sección inusualmente independiente de ARPA
encargada de apoyar los proyectos de investigación y desarrollo informáticos más avanzados del país.
La suite del director de IPTO, donde Taylor colgó su abrigo de 1965 a 1969, estaba ubicada en el anillo D. Lo que
le faltaba a su oficina en cuanto a vistas se compensaba con su comodidad y tamaño.
Era una habitación lujosamente alfombrada y ricamente amueblada, con un gran escritorio, una pesada
mesa de conferencias, estanterías con frente de cristal, cómodas sillas de cuero y todos los demás adornos
de rango, que el Pentágono midió cuidadosamente hasta la calidad de los ceniceros. (Al viajar por asuntos
militares, Taylor tenía el rango de general de una estrella).
En una pared de su oficina había un gran mapa del mundo; un calco de templo enmarcado procedente de
Tailandia colgaba de forma destacada de otro.
Dentro de la suite, al lado de la oficina de Taylor, había otra puerta que conducía a un pequeño espacio conocido
como la sala terminal. Allí, uno al lado del otro, había tres terminales de computadora, cada uno de un fabricante
diferente, cada uno conectado a una computadora central separada que se ejecutaba en tres sitios separados.
Había una terminal de máquina de escribir IBM Selectric modificada conectada a una computadora en el
Instituto Tecnológico de Massachusetts en Cambridge. Un terminal Teletipo Modelo 33, que parecía un
escritorio de metal con una gran y ruidosa máquina de escribir incorporada, estaba conectado a una
computadora en la Universidad de California en Berkeley. Y otra terminal de teletipo, un Modelo 35, estaba
dedicada a una computadora en Santa Mónica, California, llamada, de manera bastante críptica, AN/FSQ
32XD1A, apodada Q32, una máquina descomunal construida por IBM para el Comando Aéreo Estratégico. Cada
uno de los terminales de la suite de Taylor era una extensión de un entorno informático diferente (diferentes
lenguajes de programación, sistemas operativos y similares) dentro de cada uno de los mainframes distantes.
Cada uno tenía un procedimiento de inicio de sesión diferente; Taylor los conocía a todos. Pero le
resultaba molesto tener que recordar qué procedimiento de inicio de sesión utilizar para cada computadora.
Y era aún más molesto, después de iniciar sesión, verse obligado a recordar qué comandos pertenecían
a qué entorno informático. Esta era una rutina particularmente frustrante cuando tenía prisa, que era la
mayor parte del tiempo.
La presencia de tres terminales de computadora diferentes en la oficina de Taylor en el Pentágono reflejó la

fuerte conexión de la IPTO con la vanguardia de la comunidad de investigación en computación, residente
en algunas de las mejores universidades y centros técnicos del país. En total, había unos veinte investigadores
principales, que apoyaban a decenas de estudiantes de posgrado y trabajaban en numerosos proyectos, todos
ellos financiados por la pequeña oficina de Taylor, que estaba formada únicamente por Taylor y una secretaria.
La mayor parte del presupuesto de 19 millones de dólares de la IPTO se estaba enviando a laboratorios
universitarios en Boston y Cambridge, o a California, para apoyar trabajos que prometían lograr avances
revolucionarios en la informática. Bajo el paraguas de ARPA, a mediados de la década de 1960 estaba
surgiendo un creciente sentido de comunidad en la investigación informática.
A pesar de la gran variedad de proyectos y sistemas informáticos, empezaban a formarse estrechos vínculos
entre los miembros de la comunidad informática. Los investigadores se vieron en conferencias técnicas
y hablaron por teléfono; ya en 1964 algunos incluso habían comenzado a utilizar una forma de correo electrónico
para intercambiar comentarios, dentro de la proximidad muy limitada de sus computadoras centrales.
Comunicarse con esa comunidad desde la sala de la terminal junto a la oficina de Taylor fue un proceso tedioso.
El equipo era de última generación, pero tener una habitación repleta de terminales de ordenador era como
tener un estudio repleto de varios televisores, cada uno dedicado a un canal diferente. "Se hizo obvio", dijo
Taylor muchos años después, "que debíamos encontrar una manera de conectar todas estas máquinas
diferentes".
Un paraíso de investigación
El hecho de que existiera incluso una agencia dentro del Pentágono capaz de apoyar lo que algunos podrían
considerar investigación académica esotérica fue un tributo a la sabiduría de los primeros fundadores
de ARPA. La agencia había sido creada por el presidente Dwight Eisenhower en el período de crisis nacional
que siguió al lanzamiento soviético del primer satélite Sputnik en octubre de 1957. La agencia de investigación
iba a ser un mecanismo de respuesta rápida estrechamente vinculado al presidente y al secretario de
Defensa, para garantizar que Los estadounidenses nunca más serían sorprendidos en la frontera tecnológica.
El presidente Eisenhower vio que ARPA encajaba muy bien en su estrategia para frenar las intensas rivalidades
entre las ramas del ejército en torno a los programas de investigación y desarrollo. La idea de ARPA
comenzó con un hombre que no era ni científico ni soldado, sino vendedor de jabón.
A los cincuenta y dos años, Neil McElroy era un recién llegado al establishment de la defensa. Nunca había
trabajado en el gobierno, nunca había vivido en Washington y no tenía experiencia militar excepto en la
guardia nacional. Durante treinta y dos años, había ascendido en la escala corporativa de Procter & Gamble, el
gigante fabricante de jabón de Cincinnati.
McElroy, graduado de Harvard, consiguió su primer trabajo en P&G cortando sobres como empleado de correo
en el departamento de publicidad por veinticinco dólares a la semana. Se suponía que sería un trabajo de
verano; Tenía la intención de ingresar a la escuela de negocios en el otoño. Pero se quedó y empezó a
vender jabón de puerta en puerta. Pronto se convirtió en director de promoción. A partir de ahí, se abrió camino
siendo pionero en la venta de jabón en radio y televisión. La telenovela fue una creación de McElroy, sobre
la cual una vez dijo sin disculparse: “El problema de mejorar el gusto literario es responsabilidad de las
escuelas. Las telenovelas venden mucho jabón”.
En 1957, P&G vendía Ivory, Oxydol, Joy y Tide por valor de mil millones de dólares cada año. Había
perfeccionado la estrategia de promover la competencia de marcas (como si hubiera diferencias reales) entre
productos similares fabricados por la misma empresa. Y durante los últimos nueve años, el alto y atractivo
“Mac”, como lo conocía la mayoría (o “Soapy Mac de CinciO” para algunos), había sido el presidente de la
compañía, hasta que Eisenhower lo reclutó para su gabinete.
En la tarde del viernes 4 de octubre de 1957, el nuevo candidato del presidente Eisenhower a secretario de
Defensa, McElroy, estaba en Huntsville, Alabama. Ya había sido confirmado por el Senado y estaba
recorriendo instalaciones militares antes de su juramento. Un gran séquito de personal del Pentágono
acompañó el recorrido de Mac por el Arsenal de Redstone, sede del programa de cohetes del Ejército.
Aproximadamente a las seis de la tarde, en el club de oficiales, McElroy estaba hablando con el emigrado
alemán Wernher von Braun, el padre de los cohetes modernos, cuando un asistente se acercó corriendo y
anunció que los rusos habían logrado lanzar un satélite a la órbita terrestre. . Ahora, de repente, incluso antes de
asumir el cargo, McElroy se vio envuelto en una crisis de enormes proporciones. En una noche, el
logro soviético había reducido la creciente confianza y el optimismo de Estados Unidos en la posguerra a un
miedo y una desesperación cada vez mayores. De repente, “el espectro de una destrucción total”, en
palabras del presidente, se apoderó de la psique estadounidense.
Cinco días después, McElroy prestó juramento, con Washington completamente consumido en la controversia
sobre la cuestión de quién había permitido que los soviéticos le robaran el avance a la ciencia y la tecnología
estadounidenses. Algunas personas habían predicho que los soviéticos lanzarían un satélite en cumplimiento de
del Año Geofísico Internacional. “Sus anteriores sermones en el desierto fueron redimidos por los
espectáculos científicos soviéticos”, dijo un observador. "Ahora adquirió el aura de verdad revelada". “Te lo
dije” se convirtió en un símbolo de estatus. Un miedo genuino, expertos siniestros y duras críticas fluyeron en
torno a la cuestión central de la nueva amenaza soviética a la seguridad nacional. Las profecías histéricas
sobre la dominación soviética y la destrucción de la democracia eran comunes. El Sputnik era una prueba
de la capacidad de Rusia para lanzar misiles balísticos intercontinentales, decían los pesimistas, y era sólo
cuestión de tiempo antes de que los soviéticos amenazaran a Estados Unidos. Los estadounidenses que
menos entraron en pánico se resignaron a la decepción por el liderazgo de Rusia en la carrera por
explorar el espacio.
Eisenhower no había querido que un experto militar experimentado dirigiera el Pentágono; él mismo lo era. El
presidente desconfiaba del complejo militarindustrial y de los feudos de las fuerzas armadas. Su actitud hacia
ellos a veces rayaba en el desprecio.
Por el contrario, amaba a la comunidad científica. Encontró a los científicos inspiradores (sus ideas, su cultura, sus
valores y su valor para el país) y se rodeó de las mejores mentes científicas del país. Eisenhower fue el primer
presidente en organizar una cena en la Casa Blanca específicamente para seleccionar a las comunidades
científica y de ingeniería como invitados de honor, de la misma manera que los Kennedy serían más tarde
anfitriones de artistas y músicos.
Cientos de destacados científicos estadounidenses sirvieron directamente a la administración

Eisenhower en varios paneles. Se refirió a ellos con orgullo como "mis científicos". A Ike “le gustaba
considerarse uno de nosotros”, observó Detlev W. Bronk, presidente de la Academia Nacional de Ciencias.
Una vez, dos científicos prominentes desayunaron con el presidente y, cuando se marchaban, Eisenhower
comentó que el Comité Nacional Republicano se quejaba de que los científicos cercanos a él no estaban
"alborotando" lo suficiente para el Partido Republicano.
"¿No lo sabe, señor presidente?" respondió uno de los hombres con una sonrisa. "Todos los científicos son
demócratas".
“No lo creo”, respondió Eisenhower. "Pero de todos modos, me gustan los científicos por su ciencia y no por su
política".
Cuando estalló la crisis del Sputnik , Eisenhower atrajo aún más a sus científicos a su círculo. En primer
lugar, celebró una serie de reuniones privadas con destacados científicos ajenos al gobierno. Once días después
de la noticia del satélite soviético, el 15 de octubre de 1957, Eisenhower se sentó a una larga discusión con su
Comité Asesor Científico, un contingente completo de las mejores mentes de la nación. Ni él ni ninguno de
ellos estaban tan preocupados por el significado real de las Sputnik como quienes estaban usando el tema
contra Ike.
Por un lado, Eisenhower sabía mucho más de lo que podía decir públicamente sobre el estado de los
programas de misiles rusos; había visto las fotografías espía exquisitamente detalladas tomadas
desde un avión espía U2. Sabía que no había hueco para los misiles. También sabía que el ejército
estadounidense y sus contratistas tenían intereses creados en la amenaza soviética. Aún así, preguntó a
sus asesores científicos su estimación de la capacidad soviética.
Eisenhower escuchó atentamente mientras evaluaban con seriedad el significado del lanzamiento del Sputnik.
Le dijeron que, efectivamente, los rusos habían adquirido un impulso impresionante. Dijeron que
Estados Unidos perdería su liderazgo científico y tecnológico a menos que se movilizara.
Muchos de los científicos que rodeaban a Eisenhower habían estado preocupados desde principios de la
década de 1950 porque el gobierno hacía un mal uso o malinterpretaba la ciencia y la tecnología
modernas. Instaron a Eisenhower a nombrar un único asesor científico presidencial de alto nivel, “una
persona con la que pudiera vivir fácilmente”, para ayudarlo a tomar decisiones relacionadas con la
tecnología. El lanzamiento del Sputnik II apenas un mes después del primer Sputnik aumentó la presión.
El primer satélite, un objeto de 184 libras del tamaño de una pelota de baloncesto, ya era bastante malo.
Su compañero de viaje pesaba media tonelada y era casi del tamaño de un Volkswagen Bug.
Unos días después de la noticia del Sputnik II, Eisenhower dijo a la nación que había encontrado a su
hombre para la ciencia en James R. Killian Jr., presidente del Instituto Tecnológico de Massachusetts.
Killian no era un científico y hablaba eficazmente en nombre de la ciencia. El 7 de noviembre de 1957,
en el primero de varios discursos para tranquilizar al pueblo estadounidense y reducir el pánico, el
presidente anunció el nombramiento de Killian como asesor científico. Llegó tarde en el discurso, pero
apareció en primera plana al día siguiente. El presidente había establecido vínculos entre la ciencia
y la defensa y dijo que Killian "seguiría adelante con la mejora científica de nuestra defensa". La prensa
apodó a Killian como el "zar de los misiles" de Estados Unidos.
Durante la reunión del 15 de octubre con sus asesores científicos, el presidente habló de su preocupación
por la gestión de la investigación en el gobierno. "Con gran entusiasmo y determinación, el presidente
quería que los científicos le dijeran dónde pertenecía la investigación científica en la estructura del
gobierno federal", dijo Sherman Adams, asistente ejecutivo del presidente. Además, Eisenhower
les dijo que tenía un excelente hombre en el Secretario de Defensa McElroy e instó a los científicos a
reunirse con el nuevo secretario, lo cual hicieron ese mismo día.
Descubrieron que el secretario McElroy sentía un aprecio similar por ellos. Un aspecto de su carrera en P&G
del que estaba más orgulloso era la cantidad de dinero que la empresa había dedicado a investigación.
Creía en el valor de la ciencia sin restricciones, en su capacidad para producir resultados notables,
aunque no siempre predecibles. McElroy y P&G habían creado un gran laboratorio de investigación de
“cielo azul”, lo habían financiado bien y rara vez, o nunca, presionaron a sus científicos para que
justificaran su trabajo. Fue una de las primeras operaciones de investigación corporativa de este tipo, en
la que los científicos podían dedicarse a casi cualquier cosa y contaban con un buen apoyo desde arriba.
Importantes avances tecnológicos surgieron de un acuerdo similar entre las universidades y el

gobierno durante la Segunda Guerra Mundial: el radar, las armas nucleares y las grandes máquinas
calculadoras fueron el resultado de lo que Killian llamó “los métodos libres de destacados científicos e
ingenieros académicos que siempre habían estado libres de cualquier obstáculo”. regimentación y
organización”.
En consulta con Killian, cuyo apoyo fue crucial, McElroy comenzó a discutir la idea de establecer una
agencia independiente para la investigación. Quizás McElroy era consciente de que la Cámara de Comercio
de Estados Unidos había planteado la idea de crear una agencia única de investigación y desarrollo para
el gobierno federal durante las audiencias del Congreso meses antes del Sputnik. Esas conversaciones
estaban en el aire. La idea surgió ahora en conversaciones con un
Comité asesor informal de industriales astutos que se reunían periódicamente con el secretario de Defensa.
En los días inmediatamente posteriores al lanzamiento soviético, dos hombres habían ido a ver a McElroy:
el eminente físico nuclear Ernest O. Lawrence, y Charles Thomas, ex director ejecutivo de Monsanto
Chemical Company y asesor ocasional del presidente. En una reunión que duró varias horas, discutieron
la idea de una agencia de I+D fuerte y avanzada que reportaría al secretario, y ambos visitantes
instaron a McElroy a seguir adelante. El físico Herbert York, director del Laboratorio Livermore y
confidente cercano tanto de Eisenhower como de Killian, se unió a las conversaciones. Al mismo
tiempo, el propio McElroy consultaba frecuentemente con Killian y el presidente. En opinión de Killian,
las misiones tradicionales de las fuerzas armadas habían quedado obsoletas debido a la ciencia y la
tecnología modernas.
Aquí había una manera de llevar al Pentágono a la nueva era. Uno de los principales atractivos del
concepto de agencia de investigación, en opinión de McElroy, era la capacidad que le daría para gestionar
la feroz competencia dentro del DOD por los programas y presupuestos de I+D. La competencia
estaba alcanzando nuevas alturas absurdas. Los comandantes del Ejército, la Armada y la Fuerza Aérea
trataron al Sputnik como el pistoletazo de salida en una nueva carrera, cada uno compitiendo contra el
otro por la mayor parte del gasto en I+D.
McElroy creía que una agencia centralizada para proyectos de investigación avanzada reduciría la rivalidad
entre servicios al colocar los presupuestos federales de I+D sustancialmente bajo su estrecha
supervisión. Además, es casi seguro que atraería al presidente, ya que las afirmaciones a menudo
egoístas y la exageración de los intereses especiales de los militares generalmente fueron recibidas con
desdén en la Casa Blanca.
A Eisenhower le gustó la propuesta del secretario. Si bien la administración tenía planes más amplios
preparados (la creación de la Administración Nacional de Aeronáutica y del Espacio (NASA), la
aprobación de una Ley de Reorganización de la Defensa, el establecimiento de la oficina de un Director
de Investigación e Ingeniería de Defensa), esas cosas llevarían tiempo. El concepto de la Agencia
de Proyectos de Investigación Avanzada fue una respuesta que el presidente pudo señalar de
inmediato. Y le daría una agencia de I+D ágil a la que él y sus científicos podrían recurrir en el futuro.
El 20 de noviembre de 1957, McElroy fue al Capitolio por primera vez como secretario. Al declarar sobre
los programas de misiles balísticos de Estados Unidos, mencionó que había decidido crear un nuevo
"gerente único" para toda la investigación de defensa. En el corto plazo, dijo al Congreso, la nueva
agencia se encargaría de los programas de I+D espaciales y satelitales. Al día siguiente, hizo circular al
Estado Mayor Conjunto un borrador de estatuto y directiva para la nueva agencia, solicitando su
revisión y comentarios.
Los militares se enojaron ante las críticas implícitas. Una cosa era tener asesores civiles en ciencia y
tecnología, pero ahora McElroy claramente estaba invadiendo su territorio, planeando administrar y operar
una oficina central que controlaría los programas de I+D de defensa y futuros proyectos de armas.
Estaban preparados para contraatacar. El secretario de la Fuerza Aérea, James Douglas, escribió: "La
Fuerza Aérea aprecia que las propuestas sean sugerencias". Es decir, mensaje recibido, no aceptado. El
Ejército, la Armada y el Estado Mayor Conjunto devolvieron el borrador del estatuto con numerosas
revisiones. Jugaron tortuosamente con el lenguaje relativo
la autoridad contratante de la nueva agencia, sus revisiones salpicadas de cambios subversivos de palabras,
adiciones astutas y eliminaciones astutas, todas diseñadas para debilitar y confinar a la agencia.
McElroy admitió algunos puntos menores, pero dejó dos cosas claras: el director de la agencia tendría autoridad
para contratar y el alcance de la investigación de la agencia sería ilimitado.
El 7 de enero de 1958, Eisenhower envió un mensaje al Congreso solicitando fondos iniciales para el
establecimiento de la Agencia de Proyectos de Investigación Avanzada. Dos días después, dejó claro este
punto en su Mensaje sobre el Estado de la Unión. “No intento hoy juzgar las acusaciones de rivalidades de
servicio perjudiciales. Pero una cosa es segura. Sean lo que sean, Estados Unidos quiere detenerlos”.
Eisenhower también afirmó “la necesidad de un control único en algunos de nuestros proyectos de
desarrollo más avanzados” y luego dio su golpe de gracia a los generales: “Otro requisito de la
organización militar es una clara subordinación de los servicios militares a la autoridad civil debidamente
constituida. Este control debe ser real; no sólo en la superficie”.
A principios de 1958, Roy Johnson, vicepresidente de General Electric, fue nombrado primer director de ARPA;
cinco días después del nombramiento, el Congreso aprobó la financiación (como una partida en un proyecto
de ley de asignaciones de la Fuerza Aérea) y ARPA entró en funcionamiento.
En el pánico posterior al Sputnik, la carrera por el espacio exterior afectó ampliamente la vida estadounidense,
provocando un nuevo énfasis en la ciencia en las escuelas, empeorando las relaciones entre Rusia y Estados
Unidos y abriendo una compuerta para el gasto en I+D. El gasto en I+D del “desafío externo” de
Washington aumentó de 5 mil millones de dólares por año a más de 13 mil millones de dólares anuales
entre 1959 y 1964. El Sputnik inició una era dorada para la ciencia y la tecnología militares. (A mediados de la
década de 1960, el gasto total en I+D del país representaría el 3 por ciento del producto nacional bruto, un punto
de referencia que era a la vez un símbolo de progreso y una meta para otros países.)
Todos los ojos estaban puestos en ARPA cuando abrió sus puertas con una asignación de 520 millones de dólares
y un plan presupuestario de 2 mil millones de dólares. Se le dio dirección sobre todos los programas
espaciales estadounidenses y toda la investigación avanzada sobre misiles estratégicos. En 1959, se
había contratado una plantilla de unas setenta personas, número que se mantendría bastante constante durante
años. Se trataba principalmente de directores de proyectos científicos que analizaban y evaluaban
propuestas de I+D, supervisando el trabajo de cientos de contratistas.
Roy Johnson, el primer director de ARPA, era, como su jefe, un hombre de negocios. A los cincuenta y dos
años, McElroy lo reclutó personalmente y lo convenció de dejar un trabajo de 160.000 dólares en General
Electric y aceptar un trabajo de 18.000 dólares en Washington.
No sorprende que Johnson abordara la agenda de I+D de Estados Unidos como un problema de gestión.
Las habilidades de gestión eran su fuerte. Su trabajo, tal como él lo veía, era exhortar a la gente a hacer todo lo
necesario para obtener ventaja sobre los soviéticos. Discutió a menudo y vigorosamente con
salas llenas de generales y almirantes, y se enfrentó agresivamente a la Fuerza Aérea. Pronto se hizo
evidente que Johnson era un defensor serio y ruidoso de una fuerte presencia militar en el espacio exterior.
Pero, por supuesto, Killian y otros científicos del entorno de Eisenhower querían que alguien bien versado
en cuestiones científicas y tecnológicas dirigiera ARPA. A Johnson se le había ordenado contratar a un oficial
militar como su adjunto y seleccionar a un científico jefe para completar su equipo de liderazgo. El puesto
científico casi había ido a parar a Wernher von Braun, hasta que insistió en traer consigo a todo su
equipo de una docena de asociados al Pentágono. Así que a Herbert York, por quien Killian había estado
interesado, se le asignó el trabajo y se trasladó a ARPA desde el Laboratorio Lawrence Livermore. Cuando
llegó al tercer piso del Pentágono, York rápidamente colgó un gran cuadro de la luna en la pared de su
oficina. Y justo al lado colgó un marco vacío. Les dijo a los visitantes que pronto se llenaría con la primera
imagen de la cara posterior de la luna.
El resto del personal de ARPA fue reclutado entre los talentos técnicos de primer nivel de la industria en
lugares como Lockheed, Union Carbide, Convair y otros contratistas del Pentágono. El personal pasaba
los días buscando oro en un flujo torrencial de propuestas de I+D no solicitadas.
El éxito de ARPA dependió de la postura extremadamente vocal de Johnson sobre el papel de Estados Unidos
en el espacio exterior y su visión simplista de las tensiones soviéticoestadounidenses. Definió erróneamente
la misión de ARPA casi enteramente en términos militares, delineando el tipo de proyectos espaciales que
imaginaba: satélites de vigilancia global, vehículos interceptores de defensa espacial, sistemas de armas
orbitales estratégicas, satélites de comunicaciones estacionarios, estaciones espaciales tripuladas y una base
lunar.
Eisenhower y sus científicos civiles habían seguido adelante con el resto de su agenda y, a finales del verano
de 1958, la Administración Nacional de Aeronáutica y del Espacio se había convertido en ley. Casi de la noche
a la mañana, mientras Johnson insistía en una presencia militar en el espacio, los proyectos espaciales y
los programas de misiles fueron despojados de ARPA y transferidos a la NASA o de nuevo a los
servicios, dejando el presupuesto de ARPA reducido a unos miserables 150 millones de dólares. La cartera
de ARPA fue destruida y su personal quedó prácticamente sin ningún papel. Aviation Week calificó a la joven
agencia como “un gato muerto colgado en el armario de las frutas”.
Johnson renunció. Sin embargo, antes de irse, encargó a su personal que redactara un documento que
sopesara cuatro alternativas: abolir ARPA, ampliarla, no realizar cambios o redefinir su misión. Sus
analistas se lanzaron a construir un caso para la cuarta alternativa, y sólo su tenacidad salvó a la agencia de
un olvido seguro. Ellos desarrollaron una serie de objetivos para distanciar a ARPA del Pentágono
cambiando el enfoque de la agencia hacia los esfuerzos de “investigación básica” a largo plazo de la nación.
Los servicios nunca habían estado interesados en proyectos de investigación abstractos; su mundo estaba
impulsado por objetivos a corto plazo y relaciones acogedoras con los contratistas industriales.
El personal de ARPA vio la oportunidad de redefinir la agencia como un grupo que se encargaría de la
investigación “lejana” realmente avanzada.
Lo más importante de todo es que el personal de ARPA reconoció el mayor error de la agencia hasta el
momento: no había contactado a las universidades donde se estaba realizando gran parte del mejor trabajo científico.
Como era de esperar, la comunidad científica se unió al llamado a reinventar ARPA como un
Patrocinador de investigación de “alto riesgo y alta ganancia”, el tipo de taller de I+D con el que habían soñado
todo el tiempo. Su sueño se hizo realidad; ARPA recibió su nueva misión.
A medida que los rasgos de ARPA fueron tomando forma, una característica fácilmente evidente de la
agencia fue que su tamaño relativamente pequeño permitía que la personalidad de su director
impregnara la organización. Con el tiempo, se alardearía del “estilo ARPA”: libre, abierto a altos riesgos, ágil.
Otros burócratas de Washington llegaron a envidiar el modus operandi de la ARPA.
Con el tiempo, la agencia atrajo a un cuerpo de élite de defensores de la I+D de las mejores universidades y
laboratorios de investigación, que se propusieron construir una comunidad de las mejores mentes técnicas y
científicas de la investigación estadounidense.
La nueva orientación de investigación básica y proyectos especiales de la agencia se adaptaba idealmente al

cambio atmosférico en Washington provocado por la elección de John F. Kennedy. Las burocracias de
Washington respondieron con vigor al carisma de Kennedy. En el Pentágono, Robert S. McNamara, el nuevo
secretario de Defensa, lideró el cambio de la filosofía de “represalia masiva” en la postura estratégica
de Estados Unidos hacia una estrategia de “respuesta flexible” a las amenazas internacionales a la supremacía
estadounidense. La ciencia era la nueva frontera.
A principios de 1961, el segundo director de ARPA, el general de brigada Austin W. Betts, dimitió y fue
reemplazado por Jack P. Ruina, el primer científico en dirigir ARPA. Ruina tenía sólidas credenciales académicas
y cierta formación militar. Se formó como ingeniero eléctrico, había sido profesor universitario y también
había trabajado como subsecretario adjunto de la Fuerza Aérea. Se llevaba bien con los miembros de los
paneles asesores científicos de la Casa Blanca.
Una era dorada para ARPA apenas comenzaba. Ruina aportó a la agencia un estilo de gestión relajado y una
estructura descentralizada. Los detalles no le interesaban; encontrar grandes talentos sí lo hizo. Creía en elegir
a las mejores personas y dejarles elegir la mejor tecnología. Estaba convencido de dar rienda suelta a los
directores de su programa. Su trabajo, tal como él lo veía, era conseguir todo el apoyo y financiación posible
para cualquier proyecto que seleccionaran. Ruina tenía la teoría de que las personas verdaderamente talentosas
normalmente no elegirían permanecer mucho tiempo en una burocracia gubernamental, pero se les podía
convencer para que pasaran uno o dos años si se les ofrecía suficiente flexibilidad y presupuestos lo
suficientemente grandes. La rotación no le molestó. Creía que la agencia se beneficiaría de una
exposición frecuente a nuevas opiniones. Además de todo esto, también se consideraba un hombre de poco
tiempo.
Con el tiempo, Ruina elevó el presupuesto anual de ARPA a 250 millones de dólares. Las principales prioridades
fueron los proyectos de defensa contra misiles balísticos y de detección de ensayos nucleares, formulados
en términos de investigación básica. (También hubo programas como investigación del comportamiento y
comando y control que, aunque interesantes, cayeron por debajo del nivel de atención de Ruina).
Luego, en mayo de 1961, una computadora, y además muy grande, exigió su atención. En ARPA se había
iniciado un programa sobre cuestiones de mando y control militar utilizando fondos de emergencia del
Departamento de Defensa. Para el trabajo, la Fuerza Aérea había comprado el enorme y costoso Q32, una
máquina gigante que actuaría como respaldo para el sistema de alerta temprana de defensa aérea de la nación.
La máquina había sido instalada en una instalación en Santa Mónica, California, en uno de los principales
contratistas de la Fuerza Aérea, System Development Corporation.
(SDC), donde se suponía que se utilizaría para la formación de operadores y como herramienta de
desarrollo de software.
Luego, la Fuerza Aérea se vio obligada a recortar, lo que dejó a la empresa de Santa Mónica pidiendo
alguna manera de mantener a sus empleados trabajando con la computadora. La Fuerza Aérea, que ya había
invertido millones en el contrato de la COSUDE, de repente tuvo en sus manos un vergonzoso elefante
blanco en forma de una enorme y desgarbada máquina informática.
Licklider
La relación entre el ejército y las instituciones informáticas comenzó con la propia industria informática
moderna. Durante la Segunda Guerra Mundial, en medio de la necesidad percibida de una capacidad de
cálculo más rápida que la que podían proporcionar los bancos de calculadoras mecánicas
manejadas por operadores humanos, el ejército financió docenas de experimentos informáticos.
La Marina apoyó a Howard Aiken, el profesor de matemáticas de Harvard que soñaba con construir una
calculadora a gran escala y terminó con la Mark I, un tablero de distribución de quince metros de largo y
dos metros y medio de alto que podía realizar operaciones aritméticas sin intervención. de un operador.
El Ejército también apoyó el famoso proyecto de Calculadora e Integrador Numérico Electrónico (ENIAC) de
la Universidad de Pensilvania.
Más tarde, en el MIT, primero la Armada y luego la Fuerza Aérea apoyaron una computadora
llamada Whirlwind.
A principios de la década de 1950, la informática significaba hacer aritmética rápidamente. Las empresas,
especialmente los bancos, ponen sus máquinas a trabajar haciendo cálculos a gran escala. En 1953,
International Business Machines Corporation (IBM), que ya era el mayor fabricante de relojes de tiempo y de
equipos de tabulación electromecánicos del país, se lanzó al negocio de fabricar grandes computadoras
electrónicas. Éstas eran las máquinas comerciales del futuro. Las máquinas de IBM no eran
necesariamente mejores que la Univac (la sucesora de la ENIAC), pero el personal de ventas de IBM se
volvió legendario y en poco tiempo las ventas de las máquinas de IBM habían superado las de la Univac.
Luego, a finales de la década de 1950, justo cuando IBM estaba superando la marca de los mil millones de
dólares en ventas, Ken Olsen, un ingeniero individualista y franco, abandonó el Laboratorio Lincoln del MIT con
70.000 dólares en capital de riesgo para explotar comercialmente la tecnología desarrollada en torno a una
nueva máquina: la TX2 en el laboratorio Lincoln. Formó Digital Equipment Corporation para fabricar y vender
componentes de computadora, y luego construyó algo radicalmente diferente de lo que había existido antes:
una computadora más pequeña llamada minicomputadora que interactuaba directamente con el usuario. La
idea de Olsen de una computadora interactiva provino de un grupo pionero de investigadores informáticos
del MIT. A un grupo diferente, un poco más joven, se le ocurrió otro concepto dramático en informática
que estaba comenzando a tener éxito, particularmente en las instituciones académicas. Lo llamaron
“tiempo compartido” y tenía un atractivo obvio como alternativa al lento e incómodo método tradicional
de procesamiento “por lotes”.
El procesamiento por lotes era una forma de computación engorrosa. Incluso para la tarea de
programación más pequeña, era necesario perforar el código correspondiente en tarjetas de programa,
que luego se combinaban con “tarjetas de control” para encargarse de las funciones administrativas de
la computadora. Un operador de computadora introducía las tarjetas en la computadora o en
cinta magnética para su procesamiento, un lote a la vez. Dependiendo de la longitud de la cola y de la

complejidad de los programas y problemas, la espera puede ser larga. No era inusual esperar un día
o más para obtener resultados.
El tiempo compartido era, como sugiere el término, un nuevo método para brindar a muchos usuarios
acceso interactivo a computadoras desde terminales individuales. Los terminales les permitieron
interactuar directamente con la computadora central. El aspecto revolucionario del tiempo compartido fue
que eliminó gran parte de la tediosa espera que caracterizaba la computación de procesos por lotes.
El tiempo compartido proporcionó a los usuarios terminales que les permitieron interactuar
directamente con la computadora y obtener sus resultados de inmediato. “Realmente creíamos que era
una mejor manera de operar”, recordó Fernando Corbató, informático del MIT. “Supongo que si alguien
hubiera dicho: 'Te daré una máquina gratis', podríamos haber dicho: 'No necesitamos tiempo
compartido'”. Pero en aquellos días las computadoras eran algo enorme. Ocupaban grandes espacios y
requerían un mantenimiento continuo porque había muchos componentes.
“Simplemente no fueron algo casual”, continuó Corbató. “Normalmente no se pensaba en tener una
máquina personal en aquellos días; tal vez para uso exclusivo, pero no personal.
Así que realmente vimos la necesidad de intentar cambiar eso. Estábamos frustrados”. La apreciación
del tiempo compartido era directamente proporcional a la cantidad de acceso directo que uno tenía
a la computadora. Y normalmente eso significaba que cuanto más programabas, mejor entendías
el valor del acceso directo.
Lo que el tiempo compartido no pudo hacer fue eliminar la necesidad de coordinar demandas competitivas
sobre la máquina por parte de diferentes usuarios. Por su naturaleza, el tiempo compartido animaba a los
usuarios a trabajar como si tuvieran toda la máquina a su disposición, cuando en realidad sólo disponían
de una fracción de la potencia informática total. La distribución de costos entre varios usuarios
significaba que cuantos más usuarios, mejor. Por supuesto, demasiados usuarios atascaban la
máquina, ya que un alto porcentaje de los recursos de la máquina se asignaban a coordinar
los comandos de múltiples usuarios. A medida que aumentaba el número de usuarios, se dedicaban más
recursos de la computadora a la función de coordinación, lo que reducía el tiempo de procesamiento
real utilizable. Si los programadores tenían que realizar trabajos muy pequeños (como ajustar el
código o depurar un programa menor), no necesitaban una máquina potente.
Pero cuando llegó el momento de ejecutar los programas en su totalidad, muchos de los cuales utilizaban
muchos recursos de la máquina, se hizo evidente que los usuarios todavía competían entre sí por el
tiempo de computación. Tan pronto como un gran programa que requería muchos cálculos entró en la
mezcla de trabajos que se realizaban en línea, el trabajo de todos se ralentizó.
•••
Cuando la Fuerza Aérea pasó el Q32 a ARPA en 1961, Ruina no tenía a nadie que administrara el
contrato. Ruina tenía en mente un trabajo con potencial de expansión mucho más allá del contrato
único que resultaba urgente en ese momento: las computadoras, en su relación con el comando y
control, algún día podrían proporcionar información confiable y de alta velocidad sobre la cual
basar las tareas críticas. decisiones militares. Ese potencial, en gran medida incumplido, parecía
infinitamente prometedor.
Casualmente, Ruina también estaba buscando a alguien que pudiera dirigir un nuevo programa en
ciencias del comportamiento que el DOD quería que ejecutara ARPA. En el otoño de 1962, Ruina había
encontrado al candidato que podía ocupar ambos puestos: un eminente psicólogo llamado JCR Licklider.
Licklider era una elección obvia para dirigir una oficina de ciencias del comportamiento, pero un psicólogo
no era una elección obvia para supervisar una oficina gubernamental centrada en el desarrollo de
tecnología informática de vanguardia. Sin embargo, los intereses amplios e interdisciplinarios de
Licklider le convenían bien para el trabajo. Licklider había incursionado seriamente en las computadoras.
“Solía decirme que le gustaba pasar mucho tiempo frente a la consola de una computadora”, recordó
Ruina. "Dijo que se obsesionaría y se volvería una especie de adicto". Sin embargo, Licklider era mucho
más que un simple entusiasta de la informática. Durante varios años, había estado promocionando
una noción radical y visionaria: que las computadoras no eran sólo máquinas de sumar. Las
computadoras tenían el potencial de actuar como extensiones de todo el ser humano, como herramientas
que podían amplificar el alcance de la inteligencia humana y ampliar el alcance de nuestros poderes analíticos.
Joseph Carl Robnett Licklider nació en St. Louis en 1915. Hijo único y muy querido, pasó sus primeros
años alimentando su fascinación por los modelos de aviones. Sabía que quería ser científico, pero
estuvo desenfocado durante la mayor parte de sus días universitarios en la Universidad de
Washington. Cambió de concentración varias veces, de química a física, a bellas artes y, finalmente,
a psicología. Cuando se graduó en 1937, tenía títulos universitarios en psicología, matemáticas y física.
Para su tesis de maestría en psicología decidió probar el popular eslogan “Duerme más, es bueno para
ti” en una población de ratas. A medida que se acercaba a su doctorado, los intereses de Licklider se
estrecharon hacia la psicoacústica, la psicofisiología del sistema auditivo.
Para su tesis doctoral, Licklider estudió la corteza auditiva de los gatos y, cuando se mudó a Swarthmore
College, trabajó en el rompecabezas de la localización del sonido, intentando analizar la capacidad del
cerebro para determinar la distancia y la dirección de un sonido. Si cierras los ojos y le pides a alguien
que chasquee los dedos, tu cerebro te dirá aproximadamente de dónde viene el chasquido y a qué
distancia está. El enigma de la localización del sonido también se ilustra con el fenómeno del “cóctel”: en
una sala llena de gente donde se llevan a cabo varias conversaciones dentro del alcance auditivo, es
posible aislar cualquier conversación que uno elija sintonizando ciertas voces y desconectando
el resto. .
En 1942, Licklider fue a Cambridge, Massachusetts, para trabajar como investigador asociado en el
Laboratorio Psicoacústico de la Universidad de Harvard. Durante los años de la guerra, estudió los
efectos de la gran altitud en la comunicación verbal y los efectos de la estática y otros ruidos en la
recepción de los receptores de radio. Licklider realizó experimentos en bombarderos B17 y B24
a 35.000 pies. El avión no estaba presurizado y las temperaturas a bordo a menudo estaban muy por
debajo del punto de congelación. Durante una prueba de campo, el colega y mejor amigo de
Licklider, Karl Kryter, vio a Licklider ponerse blanco. Kryter entró en pánico. Subió el oxígeno y le gritó a
su amigo: “¡Lame! ¡Hablame!" Justo cuando Kryter estaba a punto de pedirle al piloto que descendiera, el
color volvió al rostro de Licklider. Había sentido un dolor tremendo, dijo, pero había pasado. Después de
eso, dejó de tomar su desayuno favorito: CocaCola.
antes de emprender misiones a gran altitud.
En ese momento, Licklider se había unido a la facultad de Harvard y estaba ganando reconocimiento como
uno de los principales teóricos del mundo sobre la naturaleza del sistema nervioso auditivo, que una vez
describió como "el producto de un arquitecto magnífico y un trabajador descuidado".
La psicología en Harvard en esos años estuvo fuertemente influenciada por el conductista BF.
Skinner y otros sostuvieron que todo comportamiento se aprende, que los animales nacen como pizarras
en blanco que deben ser inscritas por el azar, la experiencia y el condicionamiento. Cuando Skinner llegó al
extremo de poner a su propio hijo en la llamada caja Skinner para probar las teorías conductistas y otros
miembros de la facultad comenzaron a realizar experimentos similares (aunque menos radicales),
Louise Licklider se puso firme. Ningún hijo suyo iba a ir a una caja y su marido estuvo de acuerdo.
Louise solía ser la primera persona en escuchar las ideas de su marido. Casi todas las noches, después
de cenar, regresaba al trabajo durante unas horas, pero cuando llegaba a casa alrededor de las
11:00 p. m., normalmente pasaba aproximadamente una hora contándole a Louise sus últimos pensamientos.
“Crecí con sus ideas”, dijo, “desde que se plantaron las semillas por primera vez, hasta que de alguna
manera u otra las vio dar frutos”.
Todo el mundo adoraba a Licklider y, ante su insistencia, casi todo el mundo lo llamaba "Lick". Su
genio inquieto y versátil dio lugar a lo largo de los años a un culto ecléctico de admiradores.
Lick medía poco más de seis pies de altura. Tenía cabello castaño arena y grandes ojos azules. Su
característica más pronunciada era su acento suave y hogareño de Missouri, que contradecía su mente
aguda. Cuando daba charlas o dirigía coloquios, nunca preparaba un discurso. En lugar de eso, se levantaba
y hacía extensos comentarios improvisados sobre cierto problema en el que estaba trabajando. El
padre de Lick había sido un ministro bautista y Louise ocasionalmente lo reprendía al notar el
predicador que había en él. “Lick jugar con un problema en una sesión informativa o un coloquio, hablar con
ese suave acento campesino, era un tour de force”, recordó Bill McGill, un ex colega. ”Hablaba con ese
acento de Missouri Ozark, y si entrabas desde la calle, te preguntabas: ¿Quién diablos es este idiota? Pero
si estuvieras trabajando en el mismo problema y escucharas su formulación, escucharlo sería como ver
el resplandor del amanecer”.
Muchos de los colegas de Lick estaban asombrados por su capacidad para resolver problemas. Alguna
vez se le describió como el que tenía la intuición más refinada del mundo. "Él podía ver la resolución de un
problema técnico antes de que el resto de nosotros pudiéramos calcularlo", dijo McGill. "Esto lo hizo
bastante extraordinario". Lick no era un formalista en ningún aspecto y rara vez luchaba con teoremas
arcanos. “Era como un niño con los ojos muy abiertos que iba de un problema a otro, consumido
por la curiosidad. Casi todos los días tenía algún estímulo nuevo sobre un problema en el que estábamos
pensando”.
Pero vivir con Lick también tuvo sus frustraciones. Muchos creían que era humilde hasta el extremo.
A menudo se sentaba en reuniones y lanzaba ideas para que cualquiera pudiera reclamarlas. “Si alguien le
robaba una idea”, recuerda Louise, “yo golpeaba la mesa y decía que no es justo, y él decía: 'No importa
quién se lleve el crédito; importa que se haga'”. A lo largo de los muchos años que enseñó, inspiró a
todos sus estudiantes, incluso a los universitarios, a sentirse como colegas jóvenes. Su casa estaba
abierta para ellos y los estudiantes a menudo aparecían en la puerta principal.
con un capítulo de una tesis o simplemente una pregunta para él. "Levantaba el pulgar y se dirigían
a su oficina del tercer piso", dijo Louise.
En los años de la posguerra, la psicología era todavía una disciplina joven, lo que provocaba el escarnio
de quienes se dedicaban a las ciencias más duras y tenían poca paciencia ante un nuevo campo que
se ocupaba de entidades tan enigmáticas como la mente o “el factor humano”. Pero Licklider era un
psicólogo en el sentido más riguroso. Como dijo un colega, pertenecía a aquellos “cuya preocupación
consciente por la legitimidad de su actividad científica los ha vuelto más duros que muchos de sus
colegas en los campos mejor establecidos”.
En 1950, Lick se mudó al MIT para trabajar en el Laboratorio de Acústica del Instituto. Al año siguiente,
cuando el MIT creó el Laboratorio Lincoln como laboratorio de investigación dedicado a la defensa
aérea, Lick firmó para iniciar el grupo de ingeniería humana del laboratorio. La guerra fría había llegado
a dominar prácticamente toda la vida intelectual de la institución. El Laboratorio Lincoln fue una de las
manifestaciones más visibles de la alianza de la guerra fría del MIT con Washington.
A principios de la década de 1950, muchos teóricos militares temían un ataque sorpresa de bombarderos
soviéticos con armas nucleares sobre el Polo Norte. Y así como los científicos se habían unido durante la
década de 1940 para abordar la posibilidad del armamento nuclear alemán, un equipo similar se
reunió en 1951 en el MIT para abordar la percibida amenaza soviética. Su estudio se llamó Proyecto
Charles. Su resultado fue una propuesta a la Fuerza Aérea para un centro de investigación
dedicado a la tarea de crear tecnología para la defensa contra ataques aéreos. Así, rápidamente se formó
el Laboratorio Lincoln, se le dotó de personal y se puso a trabajar bajo la dirección de su primer
director, el físico Albert Hill. En 1952, el laboratorio se trasladó fuera del campus a Lexington, a unas
diez millas al oeste de Cambridge. Sus principales proyectos se centraron en el concepto de
alerta temprana distante: la línea DEW: conjuntos de radares que se extienden, idealmente, desde
Hawaii hasta Alaska, a través del archipiélago canadiense hasta Groenlandia y, finalmente, hasta Islandia y las Islas Británicas.
Los problemas de comunicación, control y análisis de una estructura tan extensa y compleja sólo
podrían resolverse mediante una computadora. Para satisfacer ese requisito, Lincoln primero asumió
Whirlwind, un proyecto informático en el MIT, y luego desarrolló un proyecto sucesor llamado Semi
Automatic Ground Environment, o SAGE.
Basado en una gran computadora IBM, SAGE era tan gigantesco que sus operadores y
técnicos literalmente caminaban dentro de la máquina. El sistema cumplía tres funciones principales:
recibir datos de varios radares de detección y seguimiento, interpretar datos relacionados con aviones
no identificados y apuntar armas defensivas a aviones hostiles entrantes. SAGE era sólo “semiautomático”,
ya que el operador humano seguía siendo una parte importante del sistema. De hecho, SAGE fue uno
de los primeros sistemas informáticos interactivos en tiempo real y en pleno funcionamiento.
Los operadores se comunicaban con la computadora a través de pantallas, teclados, interruptores
y pistolas de luz. Los usuarios podían solicitar información desde el ordenador y recibir una respuesta en
unos segundos. Nueva información fluía continuamente directamente a la memoria de la
computadora a través de líneas telefónicas hacia los usuarios, poniéndola inmediatamente a
disposición de los operadores.
El sistema SAGE inspiró a algunos pensadores, incluido Licklider, a ver la informática desde una
perspectiva completamente nueva. SAGE fue un ejemplo temprano de lo que Licklider llamaría más
tarde la "simbiosis" entre humanos y máquinas, donde la máquina funciona como un problema.
compañero de resolución. En esta relación simbiótica estaba implícita la interdependencia de

humanos y computadoras trabajando al unísono como un solo sistema. Por ejemplo, en un escenario
de batalla, los operadores humanos sin computadoras serían incapaces de calcular y analizar las
amenazas con la suficiente rapidez para contrarrestar un ataque. Por el contrario, los ordenadores que
trabajen solos no podrían tomar decisiones cruciales.
En 1953, el MIT decidió iniciar un grupo de factores humanos en la sección de psicología del
departamento de economía y Lick quedó a cargo. Reclutó a un puñado de sus estudiantes y
colegas más brillantes. Lick contrató personas no basándose en su trabajo doctoral o su posición en la
clase, sino en una prueba simple que aplicó: la Prueba de Analogías de Miller. (La prueba cubre todos
los campos, desde la geología hasta la historia y las artes. Requiere tanto un buen conocimiento general
como la capacidad de aplicar ese conocimiento a las relaciones). “Tenía una especie de regla”, dijo.
"Cualquiera que pueda obtener 85 o más en la prueba de analogías de Miller, contrátelo, porque será muy
bueno en algo".
En 1954, el grupo de Lick se mudó con psicólogos sociales y expertos en gestión laboral a la Sloan
School of Management. Pero las ideas del grupo estaban muy alejadas de los problemas de gestión.
Como lo describió McGill, uno de los primeros reclutas de Licklider, él y sus pares estaban mucho más
interesados en las computadoras y los dispositivos de memoria de las computadoras como modelos de la
versatilidad de la cognición humana. La primera tesis producida por el departamento bajo la dirección
de Lick provino del Ph.D. candidato Tom Marill, que había examinado el tema de la detección auditiva
ideal. (Al igual que otros que entraron en la esfera de Licklider, Marill dejaría su huella en el desarrollo de
las redes informáticas en los años venideros).
"Nunca antes se había visto algo así, al menos no en un departamento de psicología", dijo McGill. El
departamento fue el primer departamento de ciencias cognitivas de la historia. "El trabajo era psicología
cognitiva de base experimental, como se definiría hoy, pero en ese momento no teníamos un lenguaje
o nomenclatura adecuada".
Pero finalmente los administradores del MIT querían algo más tradicional y Lick fracasó en sus esfuerzos
por ampliar su nuevo departamento con nombramientos permanentes. Como resultado, todos sus
protegidos, jóvenes y comercializables, se quedaron dormidos. “No teníamos la sofisticación para
promocionar lo que hacíamos y no éramos conscientes de que tenía algo de único. Así que el MIT lo
dejó pasar todo”, dijo McGill. Después de todo, Lick era un inconformista y un poco extravagante, tal
vez demasiado para el MIT.
Sin embargo, Lick no lamentó la desaparición del grupo, ya que él mismo declaraba tener poca
capacidad de atención. Sus intereses cambiaron frecuente y dramáticamente a lo largo de los años.
Una vez le aconsejó a un joven amigo que nunca se inscribiera en un proyecto que durara más de
cinco o siete años, para poder dedicarse siempre a otras cosas. Y todo lo que le interesaba a Lick lo
profundizaba profundamente.
Quizás el incidente que más despertó el interés de Lick por las computadoras y su potencial como
instrumentos interactivos fue un encuentro que tuvo en la década de 1950 con un joven ingeniero
inteligente y testarudo de los Laboratorios Lincoln llamado Wesley Clark. Clark era un joven
investigador que trabajaba en la máquina TX2, lo último en computación digital y sucesora de
una computadora llamada TX0. Clark había construido el TX0 con Ken Olsen antes de que Olsen se
fuera para fundar Digital Equipment Corporation.
La oficina de Clark estaba en el sótano de Lincoln. Un día, al regresar del almacén al otro
extremo del pasillo, Clark decidió aventurarse en una habitación que siempre había parecido vagamente
prohibida. La mayoría de las puertas de los laboratorios estaban abiertas, pero ésta no. Siempre estuvo
cerrado. Clark probó la puerta, que se sorprendió al encontrar abierta, y entró en la habitación. “Entré y volví
a través de un pequeño laberinto de deflectores y barreras”.
Clark recordó. “A un lado estaba un laboratorio muy oscuro y entré, y después de explorar un rato en
la oscuridad encontré a este hombre sentado frente a unas pantallas.
Estaba haciendo algún tipo de psicometría y claramente era un tipo interesante. Me interesé en lo que
estaba haciendo y en su aparato y, según recuerdo, le sugerí que podía lograr los mismos resultados
usando una computadora”. El hombre era Licklider.
Clark invitó a Lick a recorrer el pasillo para ver el TX2 y aprender algunos conceptos básicos.
Enseñarle a Lick a programar la máquina habría sido demasiado difícil.

Programar una computadora como la TX2 era una especie de arte negro. El TX2, que contenía 64.000
bytes de memoria (tanto como una simple calculadora de mano en la actualidad), ocupaba un par de
habitaciones. Lo que muchos años más tarde se convirtieron en pequeños microchips para la unidad
central de procesamiento de la computadora eran, en aquellos días, enormes bastidores de muchas
unidades enchufables independientes, cada una de las cuales constaba de docenas de transistores y
piezas electrónicas asociadas. Se ocupó aún más espacio con grandes consolas cubiertas con
interruptores y luces indicadoras para ayudar al operador o al solucionador de problemas a comprender
qué estaba haciendo el sistema. Todo este equipo requería bastidor tras bastidor de equipo, de los cuales
sólo una pequeña fracción (la pantalla de vídeo y el teclado) podrían ser reconocibles hoy como piezas
ordinarias de computadora. “Sentarse en el TX2 con Lick era verse inmerso en una maraña de cosas aparentemente irrelevantes”,
Convertirse en un “usuario” de TX2 habría sido un ejercicio desalentador incluso para alguien tan
rápido como Licklider. Por un lado, no había herramientas de enseñanza per se, ni ayudas didácticas
ni menús de ayuda. Por otro lado, el sistema operativo que estandarizaría la programación de la
máquina aún no se había escrito.
Una cosa que el TX2 hizo muy bien fue mostrar información en pantallas de video. Eso la convirtió en
una de las primeras máquinas para trabajos de gráficos interactivos. Fue esta característica la que ayudó a
Clark a demostrarle a Lick las ideas principales del uso interactivo.
Las sesiones con Clark dejaron una impresión imborrable en Lick. Se alejó más de la psicología y se
acercó a la informática. A medida que sus intereses cambiaron, la creencia de Lick en el potencial de las
computadoras para transformar la sociedad se convirtió en una especie de obsesión.
Sucumbiendo al atractivo de la informática, empezó a pasar horas seguidas delante de la consola de
visualización interactiva. Louise creía que si no le pagaran por este trabajo, le habría pagado por hacerlo.
La idea sobre la que giraba la visión del mundo de Lick era que el progreso tecnológico salvaría a la
humanidad. El proceso político era uno de sus ejemplos favoritos. En una visión McLuhanesca del poder
de los medios electrónicos, Lick vio un futuro en el que, gracias en gran parte al alcance de las
computadoras, la mayoría de los ciudadanos estarían “informados sobre el proceso de gobierno,
interesados e involucrados en él”. Imaginó lo que llamó “consolas informáticas domésticas” y televisores
conectados en una red masiva. “El proceso político”, escribió, “sería esencialmente una
teleconferencia gigante, y una campaña
Será una serie de comunicaciones de meses de duración entre candidatos, propagandistas,

comentaristas, grupos de acción política y votantes. La clave es la euforia automotivadora que
acompaña a la interacción verdaderamente efectiva con la información a través de una buena consola y una
buena red con una buena computadora”.
Las ideas de Lick sobre el papel que podrían desempeñar las computadoras en la vida de las personas
alcanzaron un punto culminante en 1960 con la publicación de su artículo fundamental "Simbiosis hombre
computadora". En él destiló muchas de sus ideas en una tesis central: un estrecho acoplamiento entre los
humanos y “los miembros electrónicos de la asociación” eventualmente daría como resultado una toma
de decisiones cooperativa. Además, las decisiones serían tomadas por humanos, utilizando computadoras,
sin lo que Lick llamó “una dependencia inflexible de programas predeterminados”. Mantuvo la opinión de que las
computadoras, naturalmente, seguirían utilizándose para lo que mejor hacen: todo el trabajo de memoria. Y esto
liberaría a los humanos para dedicar energía a tomar mejores decisiones y desarrollar conocimientos más
claros de los que serían capaces sin las computadoras.
Juntos, sugirió Lick, el hombre y la máquina funcionarían de manera mucho más competente que cada uno
de ellos por separado. Además, atacar los problemas en colaboración con las computadoras podría ahorrar
el más valioso de los recursos posmodernos: el tiempo. “La esperanza”, escribió Licklider, “es que en no
muchos años los cerebros humanos y las máquinas informáticas estén acoplados. . . estrechamente, y que
la asociación resultante pensará como ningún cerebro humano ha pensado jamás y procesará datos de una
manera que no lo hacen las máquinas de manejo de información que conocemos hoy”.
Las ideas de Licklider, que tuvieron sus inicios apenas unos años antes en un encuentro casual en el
sótano del Laboratorio Lincoln, representaron algunas de las ideas más atrevidas e imaginativas de la
época. Un ex alumno del MIT, Robert Rosin, que había tomado un curso de psicología experimental en Lick
en 1956 y luego se dedicó a la informática, leyó “Simbiosis hombrecomputadora” y quedó asombrado
por la versatilidad intelectual del anciano. "Por mi vida, no podría imaginar cómo un psicólogo que, en 1956,
no tenía aparentes conocimientos de computadoras, podría haber escrito un artículo tan profundo y esclarecedor
sobre 'mi campo' en 1960", dijo Rosin. "El artículo de Lick me causó una profunda impresión y refinó mi propia
comprensión de que se avecinaba una nueva era de la informática".
En el momento en que Licklider publicó el artículo, su reputación como informático quedó fijada para siempre.
Se deshizo del manto de la psicología y se dedicó a la informática. No había forma de darle marcha atrás. Un
par de años antes de que se publicara el artículo, Licklider había dejado el MIT para trabajar en una pequeña
empresa de consultoría e investigación en Cambridge llamada Bolt Beranek and Newman. La empresa había
acordado comprarle dos ordenadores para su investigación y estaba pasando el mejor momento de su vida.
Un día de 1962, el director de ARPA, Jack Ruina, llamó a Licklider para ofrecerle una nueva posibilidad laboral.
¿Qué diría Lick de asumir no sólo la división de mando y control de ARPA, sino también una nueva división de
ciencias del comportamiento? Y habría una computadora enorme, la Q32, incluida en el trato.
Ruina también visitó a Fred Frick, amigo y colega de Lick en el Laboratorio Lincoln. Frick y Licklider se
reunieron juntos con Ruina. Licklider entró preparado sólo para escuchar, pero pronto se volvió elocuente
sobre el tema. Los problemas de mando y control, le dijo a Ruina,
eran esencialmente problemas de interacción personacomputadora. “Pensé que era simplemente

ridículo tener sistemas de comando y control basados en el procesamiento por lotes”, recordó años
después. "¿Quién puede dirigir una batalla cuando tiene que escribir el programa en medio de la batalla?"
Licklider y Frick coincidieron en que el trabajo parecía interesante, pero ninguno quería dejar lo que
estaba haciendo.
Sin embargo, el argumento de venta de Ruina fue tan intenso e hizo que la misión pareciera tan crítica,
que Frick y Licklider decidieron que uno de ellos debería hacerlo. Lanzaron una moneda y Lick aceptó el
puesto con la condición de que se le diera la libertad de dirigir el programa en cualquier dirección que
considerara adecuada. En parte porque Ruina estaba muy ocupada y en parte porque él mismo no
entendía de computadoras, aceptó la condición sin dudarlo.
Lick pertenecía a un pequeño grupo de informáticos que creían que las personas podrían ser mucho más
eficaces si tuvieran a su alcance un sistema informático con buenas pantallas y buenas bases de datos.
Antes de mudarse a Washington en el otoño de 1962, Lick impartió una serie de seminarios sobre informática
en el Pentágono, a los que asistieron numerosos funcionarios militares y del Departamento de Defensa. Su
mensaje, que ya era una especie de mantra en Cambridge pero todavía en gran medida desconocido para
el público militar, era que una computadora debería ser algo con lo que cualquiera pudiera interactuar
directamente, eliminando a los operadores de computadoras como intermediarios para resolver sus
problemas.
Con este fin, Lick vio una gran promesa en el tiempo compartido y fue uno de sus evangelistas más
ardientes. El tiempo compartido no puso exactamente una computadora en el escritorio de todos,
pero creó la ilusión de eso. Puso el poder de la computadora al alcance de todos. Le dio a la gente una
fuerte sensación de la máquina.
La promoción del tiempo compartido no fue de ninguna manera la única misión de Lick cuando llegó a
ARPA. Estaba igualmente interesado en explorar las ideas que se habían estado filtrando en torno a la
interacción hombremáquina durante varios años.
Cuando Lick llegó para su primer día de trabajo, el 1 de octubre de 1962, su secretaria le dijo: “Bueno, Dr.
Licklider, hoy sólo tiene una cita. Vienen algunos señores de la Oficina de Presupuesto para revisar su
programa”. Cuando llegaron los responsables del presupuesto, se divirtieron al descubrir que era el
primer día de Licklider. No había mucho material que discutir todavía. El programa de mando y control
consistía en un contrato de 9 millones de dólares (con System Development Corporation) y los 5 millones
de dólares restantes del presupuesto todavía estaban sin asignar. En lugar de una revisión del presupuesto,
la reunión se transformó en un coloquio privado, en el que Lick expuso temas como el tiempo compartido, la
informática interactiva y la inteligencia artificial. Como muchos otros antes que ellos, los contables
quedaron infectados por el entusiasmo de Licklider. “Les dije lo que me entusiasmaba y eso resultó
ser muy favorable para mí, porque se interesaron en ello”, dijo más tarde. “Y cuando tuvimos una reunión
sobre el tema, no me quitaron nada de mi dinero”.
El mandato principal que le habían dado era encontrar usos para las computadoras además de ser
herramientas para cálculos científicos numéricos. Lick desarrolló nuevos programas en parte como
reacción contra algunas de las aplicaciones que el Departamento de Defensa tenía en mente para
computadoras grandes. La inteligencia de la Fuerza Aérea, por ejemplo, quería aprovechar enormes computadoras centrales para
Detectar patrones de comportamiento entre funcionarios soviéticos de alto nivel. La computadora

recibiría información de inteligencia de una variedad de fuentes humanas, como rumores de cócteles
u observaciones en un desfile del Primero de Mayo, y trataría de desarrollar un escenario con la
mejor suposición sobre lo que podrían estar haciendo los soviéticos. “La idea era tomar esta poderosa
computadora y alimentarla con toda esta información cualitativa, como 'El jefe de la fuerza aérea bebió
dos martinis' o 'Khrushchev no lee Pravda los lunes'”, recordó Ruina. "Y la computadora haría el
papel de Sherlock Holmes y concluiría que los rusos deben estar construyendo un misil MX72 o algo
así".
Primero Ruina, luego Licklider, intentaron poner fin a este tipo de “cosas estúpidas”, como Lick
describió los proyectos mal concebidos. Luego, Lick trabajó para encontrar los centros informáticos
más importantes del país y establecer contratos de investigación con ellos. En poco tiempo, se acercó
a los mejores científicos informáticos del momento, de Stanford, MIT, UCLA, Berkeley y un puñado de
empresas, introduciéndolos en la esfera de ARPA. En total, había alrededor de una docena en el
círculo íntimo de Lick, al que Ruina llamó "el sacerdocio de Lick". De manera típica, cuando sus
creencias más apasionadas se disfrazaban de broma, Licklider la apodó Red Intergaláctica de
Computadoras.
Seis meses después de su llegada a ARPA, Lick escribió un extenso memorando a los miembros de
la Red Intergaláctica en el que expresaba su frustración por la proliferación de lenguajes de
programación, sistemas de depuración, lenguajes de control de sistemas de tiempo compartido
y esquemas de documentación dispares. Al defender un intento de estandarización,
Lick discutió el problema hipotético de una red de computadoras.
"Consideremos la situación en la que varios centros diferentes están conectados, cada uno de los
cuales es muy individualista y tiene su propio lenguaje especial y su propia forma especial de hacer
las cosas", planteó. “¿No es deseable o incluso necesario que todos los centros se pongan de
acuerdo sobre algún lenguaje o, al menos, sobre algunas convenciones para formular preguntas
como '¿Qué idioma habla usted?' En este extremo, el problema es esencialmente el que discuten
los Escritores de ciencia ficción: ¿Cómo se inician las comunicaciones entre seres inteligentes
totalmente no correlacionados?
Dicho esto, Lick cubrió sus apuestas. “Posiblemente suceda”, continuó, “que sólo en raras
ocasiones la mayoría o todos los ordenadores del sistema general funcionen juntos en una red
integrada. Sin embargo, me parece importante desarrollar una capacidad para el funcionamiento
integrado de la red”. Y ahí estaba la semilla de la visión más grandiosa de Licklider hasta el momento.
Ampliaría el concepto de Red Intergaláctica para referirse no sólo a un grupo de personas a las que
enviaba notas, sino a un universo de ordenadores interconectados a través de los cuales todos podían
enviar sus notas.
Licklider no fue una excepción a la regla de que la gente no pasaba mucho tiempo en ARPA. Pero
cuando se fue en 1964, había logrado cambiar el énfasis de la agencia en la I+D informática
de un laboratorio de sistemas de comando que representaba escenarios de juegos de guerra a una
investigación avanzada en sistemas de tiempo compartido, gráficos por computadora y lenguajes
informáticos mejorados. El nombre de la oficina, Investigación de Comando y Control, había
cambiado para reflejar ese cambio, convirtiéndose en Oficina de Técnicas de Procesamiento de
Información. Licklider eligió a su sucesor, un colega llamado Ivan Sutherland, el principal experto
mundial en gráficos por ordenador. En 1965, Sutherland contrató a un joven destacado llamado Bob Taylor, quien
Pronto se sentaría en la sala terminal de ARPA y se preguntaría por qué, con tantas
computadoras, no podían comunicarse entre sí.
La idea de Taylor
Bob Taylor había comenzado la universidad en Dallas a la edad de dieciséis años pensando que
seguiría los pasos de su padre y se convertiría en ministro. Su familia nunca vivió en un lugar por
mucho tiempo, mudándose de una iglesia metodista a otra en Texas, en pueblos con nombres como
Uvalde, Victoria y Ozona. Pero en lugar de servir al Señor, Taylor entró al servicio de la Marina de
los EE. UU. cuando su unidad de reserva fue llamada al servicio activo para la Guerra de Corea.
Taylor pasó la guerra en la Estación Aérea Naval de Dallas, “el USSNeverfloat ”, lo llamó.
Al final de la guerra, ingresó a la Universidad de Texas con el GI Bill sin ningún curso de estudio en
particular en mente. Finalmente se graduó en 1957 con especialización en psicología y especialización
en matemáticas.
Taylor persiguió su amor por la ciencia en la escuela de posgrado de UT y escribió su tesis sobre
psicoacústica, un campo desde el cual algunas personas estaban dando un salto hacia la informática.
Taylor también saltó. "Cuando estaba en la escuela de posgrado, no existía la informática".
Taylor recordó: “Así que realmente no tuve mucha introducción a la informática. Pero comencé a
sentir que la investigación en informática iba a ser mucho más gratificante”.
Recién salido de la escuela, Taylor tuvo algunos trabajos en la industria aeroespacial antes de
conseguir un trabajo en la NASA en 1961, donde trabajó como oficial de programas en
Washington, DC, en la Oficina de Investigación y Tecnología Avanzada. Un día de 1963, Taylor fue
invitado a unirse a un comité no oficial de administradores de programas gubernamentales,
todos los cuales participaban en la financiación de la investigación informática. Era un grupo informal
que simplemente intercambiaba información sobre sus proyectos, buscaba formas de colaborar
y trataba de evitar duplicaciones o superposiciones. Resultó que la invitación procedía de alguien que
había sido el modelo intelectual de Taylor en psicoacústica: JCR Licklider. Era el jefe del comité.
Los primeros trabajos de Licklider en psicoacústica habían influido profundamente en los del propio
Taylor y agradeció la oportunidad de conocer al ilustre Licklider.
A Taylor le sorprendió lo modesto que era. “Me halagó desde el principio al decir que conocía mi
trabajo de tesis”, dijo Taylor. Aquí estaba un hombre con una gran reputación que probablemente
era una de las personas más amables y tranquilas que Taylor había conocido jamás.
Cuando Taylor se unió por primera vez al comité, Licklider estaba en el proceso de reunir a la
comunidad informática bajo ARPA, la nueva generación de investigadores atraídos por la computación
interactiva. Estaban ocupados formulando su nueva y audaz perspectiva, radicalmente diferente de la
corriente principal en la investigación y el desarrollo informático durante las dos décadas anteriores. Se
habían invertido montañas de dinero y años de trabajo para mejorar los parámetros técnicos de
velocidad, confiabilidad y tamaño de la memoria de las computadoras. Pero esta pequeña vanguardia
de investigadores concentrada en el MIT y alrededor de Boston había comenzado a trabajar para hacer
de la computadora un amplificador del potencial humano, una extensión de la mente y el cuerpo.
Taylor era conocido por tener bastante intuición. Se le consideraba un responsable de

programas con visión de futuro y que tenía una habilidad especial para elegir ganadores
innovadores, tanto de proyectos como de investigadores. Se unió a ARPA a principios de 1965, tras la
partida de Licklider, para trabajar como adjunto de Ivan Sutherland, segundo director de IPTO. Meses
después, en 1966, a la edad de treinta y cuatro años, Taylor se convirtió en el tercer director de IPTO,
heredando la responsabilidad de la comunidad y gran parte de la visión (de hecho, la oficina
misma) establecida por Licklider. La única diferencia, que resultó ser crucial, fue que ARPA (ahora
dirigida por Charles Herzfeld, un físico austríaco que había huido de Europa durante la guerra)
fue incluso más rápido y más flexible con su dinero que durante el mandato de Ruina. Ahora circulaba
un chiste entre los directores de sus programas: si se les ocurre una buena idea para un programa
de investigación, tardarán unos treinta minutos en conseguir la financiación.
El “problema terminal”, como lo llamó Taylor, fue una fuente de frustración no sólo para él sino
también para Sutherland antes que él y para Licklider antes. Un día, poco después de
convertirse en director de IPTO, Taylor se encontró dando vueltas a una idea que Lick había discutido
con él varias veces pero que nunca había puesto en práctica. Ahora que era su turno, Taylor decidió
actuar.
Taylor se dirigió directamente a la oficina de Herzfeld. Sin notas. Sin reuniones. Otros directores
de programa se sintieron un poco intimidados por Herzfeld, un hombre corpulento con un
marcado acento vienés. Pero Taylor no vio nada que temer sobre el hombre. De hecho, Taylor se
comportaba como un niño tan bueno con su jefe que una vez alguien le preguntó: “Taylor, ¿qué
tienes con Herzfeld? Debes estar relacionado con Lyndon Johnson. Ambos sois de Texas, ¿no?
Taylor le dijo al director de ARPA que necesitaba discutir la financiación de un experimento de networking
que tenía en mente. Herzfeld ya había hablado un poco sobre establecer contactos con Taylor, por
lo que la idea no era nueva para él. También visitó la oficina de Taylor, donde fue testigo del
molesto ejercicio de iniciar sesión en tres computadoras diferentes. Y unos años antes incluso había
caído bajo el hechizo del propio Licklider cuando asistía a sus conferencias sobre informática interactiva.
Taylor le dio a su jefe un breve informe: los contratistas de IPTO, la mayoría de los cuales estaban en
universidades de investigación, estaban comenzando a solicitar más y más recursos
informáticos. Al parecer, cada investigador principal quería su propia computadora. No sólo
había una evidente duplicación de esfuerzos en toda la comunidad investigadora, sino que además
se estaba volviendo condenadamente caro. Las computadoras no eran pequeñas ni baratas. ¿Por qué
no intentar unirlos todos? Al construir un sistema de enlaces electrónicos entre máquinas, los
investigadores que realizan trabajos similares en diferentes partes del país podrían compartir
recursos y resultados más fácilmente. En lugar de distribuir media docena de costosas
computadoras centrales por todo el país dedicadas a respaldar la investigación gráfica avanzada,
ARPA podría concentrar recursos en uno o dos lugares y crear una manera para que todos
puedan acceder a ellos. Una universidad podría concentrarse en una cosa, otro centro de
investigación podría recibir fondos para concentrarse en otra cosa, pero independientemente de
dónde estuvieras ubicado físicamente, tendrías acceso a todo. Sugirió que ARPA financie una
pequeña red de prueba, comenzando con, digamos, cuatro nodos y llegando hasta una docena aproximadamente.
El Departamento de Defensa era el mayor comprador de ordenadores del mundo. Invertir en una marca
particular de computadora no era una decisión trivial y, a menudo, ponía en aprietos a los diferentes
servicios, particularmente cuando se enfrentaba a una norma federal que dictaba que todos los
fabricantes tuvieran las mismas oportunidades. No parecía haber esperanzas de limitar la compra
de toda una variedad de máquinas. Y las posibilidades de que el mundo de la informática
gravitara en el corto plazo hacia un conjunto de estándares operativos uniformes parecían escasas o inexistentes.
Los patrocinadores de la investigación como ARPA simplemente tendrían que encontrar alguna otra
manera de superar los problemas de incompatibilidad de la industria. Si la idea de la red funcionara,
Taylor le dijo a Herzfeld, sería posible conectar computadoras de diferentes fabricantes y el
problema de elegir computadoras se reduciría considerablemente. Herzfeld estaba tan cautivado por
esa posibilidad que esos argumentos por sí solos podrían haber sido suficientes para convencerlo. Pero
había otra ventaja, centrada en la cuestión de la fiabilidad. Podría ser posible conectar computadoras
en una red de forma redundante, de modo que si una línea fallara, un mensaje pudiera tomar otra ruta.
“¿Va a ser difícil hacerlo?” Preguntó Herzfeld.
"Oh, no. Ya sabemos cómo hacerlo”, respondió Taylor con su característica audacia.
"Gran idea", dijo Herzfeld. “Ponlo en marcha. Tienes un millón de dólares más en tu presupuesto
ahora mismo. Ir."
Taylor salió de la oficina de Herzfeld en el anillo E y se dirigió de regreso al corredor que conectaba con
el anillo D y su propia oficina. Echó un vistazo a su reloj. “Jesucristo”, se dijo a sí mismo en voz
baja. "Eso sólo tomó veinte minutos".
2
Una cuadra aquí, algunas piedras allá
Cuando Taylor asumió la dirección de IPTO en 1966, las manifestaciones de la filosofía de

Licklider eran evidentes en todo el sector de la investigación informática. Las filas de investigadores que
esperaban llevar la computadora más allá del estatus de instrumento de cálculo continuaron
creciendo a lo largo de la década. Algunos de los primeros y más importantes trabajos en gráficos
interactivos y realidad virtual se llevaron a cabo en la Universidad de Utah utilizando dinero
ARPA. El MIT, en particular, pareció generar un desarrollo innovador tras otro. Allí, Marvin
Minsky y Seymour Papert realizaron importantes trabajos iniciales en inteligencia artificial. Los
programas en otras instituciones se centraron en técnicas de programación avanzadas, tiempo
compartido y lenguajes informáticos.
Construir una red como un fin en sí mismo no era el objetivo principal de Taylor. Estaba tratando de
resolver un problema que había visto empeorar con cada ronda de financiación. Los investigadores
estaban duplicando y aislando costosos recursos informáticos. Los científicos de cada sitio no sólo
participaban en investigaciones informáticas cada vez más diversas, sino que sus demandas de
recursos informáticos crecían más rápidamente que el presupuesto de Taylor. Cada nuevo proyecto
requirió la creación de una nueva y costosa operación informática. Dependiendo de la computadora que se
utilizara y del número de estudiantes de posgrado que recibían apoyo, las subvenciones individuales de
la IPTO oscilaban entre 500.000 y 3 millones de dólares.
Y ninguno de los recursos o resultados se compartió fácilmente. Si los científicos que hacían gráficos en Salt
Lake City querían utilizar los programas desarrollados por la gente del Laboratorio Lincoln, tenían que volar a
Boston. Aún más frustrante es que, si después de un viaje a Boston, personas de Utah quisieran iniciar un
proyecto similar en su propia máquina, tendrían que gastar mucho tiempo y dinero duplicando lo que
acababan de ver. En aquellos días, los programas de software eran únicos, como obras de arte originales, y
no se transferían fácilmente de una máquina a otra. Taylor estaba convencido de la viabilidad técnica
de compartir dichos recursos a través de una red informática, aunque nunca se había hecho.
Más allá de la reducción de costos, la idea de Taylor reveló algo muy profundo. La capacidad de una
máquina para amplificar el poder intelectual humano era precisamente lo que Licklider había tenido en mente
mientras escribía su artículo sobre la simbiosis hombremáquina seis años antes. Por supuesto, las
ideas de Licklider sobre el tiempo compartido ya estaban dando frutos en universidades de todo el país. Pero la
idea de establecer contactos marcó un alejamiento significativo del tiempo compartido. En una red de recursos
compartidos, muchas máquinas servirían a muchos usuarios diferentes, y un investigador interesado en
utilizar, digamos, un programa de gráficos concreto en una máquina a tres mil kilómetros de distancia
simplemente se conectaría a esa máquina. La idea de que una computadora buscara recursos dentro de
otra, como pares en una organización colaborativa, representaba la concepción más avanzada que aún
había surgido de la visión de Licklider.
Taylor tenía el dinero y el apoyo de Herzfeld, pero necesitaba un director de programa que pudiera
supervisar el diseño y la construcción de dicha red, alguien que no sólo conociera las ideas de Licklider sino que
creyera en ellas. Esta persona tenía que ser un informático de primer nivel y sentirse cómodo con una amplia
gama de cuestiones técnicas.
Cómo lograrlo no preocupaba mucho a Taylor, siempre y cuando la red fuera confiable y rápida. Ésas
eran sus prioridades. La informática interactiva significaba que se obtendría una respuesta rápida de una
computadora, por lo que en el entorno informático moderno tenía sentido que una red también tuviera una gran
capacidad de respuesta. Y para ser útil, tenía que estar funcionando en cualquier momento que lo necesitaras.
Quien diseñara una red de este tipo debía ser también un experto en sistemas de telecomunicaciones.
No fue una combinación fácil de encontrar. Pero Taylor ya tenía a alguien en mente: un joven informático
tímido y reflexivo del caldo de cultivo de los Laboratorios Lincoln llamado Larry Roberts.
A principios de 1966, Roberts estaba en Lincoln trabajando en gráficos. Pero también había trabajado bastante
en comunicaciones. Acababa de completar uno de los experimentos de prueba de principio más relevantes en
redes hasta la fecha, conectando dos computadoras a un continente de distancia. Taylor había financiado el
experimento de Roberts. Había tenido suficiente éxito como para aumentar la confianza de Taylor y
convencerse tanto a él como a Herzfeld de que era factible una red un poco más compleja. Y el conocimiento de
Roberts sobre las computadoras fue profundo. Roberts, hijo de químicos de Yale, había asistido al MIT y
recibió su introducción a las computadoras en el TX0. Aunque fue la primera computadora digital transistorizada,
la TX0 era limitada (la resta no estaba en su repertorio; sólo podía restar sumando un número negativo).
Utilizando el TX0, Roberts aprendió por sí mismo los conceptos básicos del diseño y funcionamiento de computadoras.
De hecho, Roberts había escrito el sistema operativo completo para su sucesor, la computadora
TX2 en Lincoln, que Wes Clark (quien construyó la TX0 con Ken Olsen) había mostrado
fatídicamente a Licklider. Cuando Clark dejó Lincoln en 1964, el trabajo de supervisar el TX2 recayó en
Roberts.
Taylor no conocía muy bien a Roberts. Al parecer, nadie conocía muy bien a Roberts. Era tan reservado
en sus modales como Taylor abierto en los suyos. Las personas con las que Roberts trabajó más
estrechamente no sabían casi nada sobre su vida personal. Lo que se sabía de él era que, además de
conocimientos en informática y telecomunicaciones, tenía habilidad para la gestión. El estilo de Roberts era
sencillo, directo, inequívoco y tremendamente eficaz.
Roberts tenía fama de ser una especie de genio. A los veintiocho años, había hecho más en el campo de
la informática de lo que muchos científicos lograrían en toda su vida. Dotado de una resistencia increíble,
trabajaba hasta muy tarde. También era un estudiante rápido: más de unas pocas personas habían
tenido la experiencia de explicarle a Roberts algo en lo que habían estado trabajando intensamente durante
años, y descubrieron que en pocos minutos lo había captado, le había dado vueltas en su cabeza un par
de veces. de veces, y ofreció sus propios comentarios mordaces. Roberts le recordó un poco a Taylor a
Licklider, pero sin el sentido del humor de Lick.
Roberts también era conocido por su capacidad casi obsesiva para sumergirse en un desafío, invirtiendo
intensos poderes de concentración en un problema. Un colega recordó una vez la vez que Roberts tomó
un curso de lectura rápida. Rápidamente duplicó su ya rápido ritmo de lectura, pero no se detuvo allí.
Profundizó en la literatura profesional sobre la lectura rápida y siguió esforzándose hasta leer a un ritmo
fenomenal de unas treinta mil palabras por minuto con un 10 por ciento de "comprensión selectiva",
como lo describió Roberts. Después de unos meses, el factor limitante de Roberts no tenía nada
que ver con sus ojos ni con su cerebro sino con la velocidad con la que podía pasar las páginas. “Tomaba un
libro de bolsillo y lo terminaba en diez minutos”, observó el amigo. "Era típico de Larry".
Taylor llamó a Roberts y le dijo que le gustaría venir a Boston a verlo. Unos días más tarde, Taylor estaba
sentado en la oficina de Roberts en el Laboratorio Lincoln, contándole sobre el experimento que
tenía en mente. Mientras Taylor hablaba, Roberts murmuró un "hmmhmm" nasal como si dijera "por favor
continúa". Taylor describió no sólo el proyecto sino también una oferta de trabajo. Roberts sería
contratado como director de programa para la red experimental, en el entendido de que sería el siguiente en
la fila para ocupar la dirección de IPTO. Taylor dejó en claro que este proyecto contaba con el apoyo
total del director de ARPA y que a Roberts se le daría amplia libertad para diseñar y construir la red como
mejor le pareciera. Taylor esperó una respuesta.
"Lo pensaré", dijo Roberts rotundamente.
Taylor interpretó esto como una forma educada de Roberts de decir no y abandonó Boston desanimado.
En cualquier otra circunstancia, simplemente habría tachado a Roberts de la lista y habría llamado a su
segunda opción. Pero no tenía una segunda opción. Roberts no sólo tenía los conocimientos técnicos
necesarios, sino que Taylor sabía que escucharía a Licklider y Wes Clark, quienes apoyaban la idea de
Taylor.
Unas semanas más tarde, Taylor hizo un segundo viaje a Lincoln. Esta vez Roberts fue más comunicativo. Le
dijo a Taylor de manera cortés pero inequívoca que disfrutaba de su trabajo en Lincoln y que no tenía ningún deseo
de convertirse en un burócrata de Washington.
Desconsolado, Taylor fue a Cambridge para visitar a Lick, quien ahora estaba de regreso en el MIT inmerso
en un esfuerzo de investigación sobre el tiempo compartido llamado Proyecto MAC. Discutieron quién más podría
ser adecuado para el trabajo. Lick sugirió a algunas personas, pero Taylor las rechazó. Quería a Roberts. A
partir de entonces, aproximadamente cada dos meses, durante las visitas a los otros contratistas de ARPA
en el área de Boston, Taylor llamó a Roberts para intentar persuadirlo de que cambiara de opinión.
Había pasado casi un año desde la conversación de veinte minutos de Taylor con Herzfeld, y la idea de establecer
contactos estaba fracasando por falta de un director de programa. Un día a finales de 1966, Taylor regresó a la oficina
del director de ARPA.
"¿No es cierto que ARPA le está dando a Lincoln al menos el cincuenta y uno por ciento de su financiación?"
Taylor le preguntó a su jefe.
“Sí, lo es”, respondió Herzfeld, un poco desconcertado.
Luego, Taylor explicó la dificultad que estaba teniendo para conseguir que el ingeniero que quería ejecutara el
programa de redes.
"¿Quién es?" Preguntó Herzfeld.
Taylor le dijo. Luego le hizo otra pregunta a su jefe. ¿Herzfeld llamaría al director del Laboratorio Lincoln y
le pediría que llamara a Roberts y le dijera que sería mejor para él y para Lincoln aceptar aceptar el trabajo en
Washington?
Herzfeld cogió el teléfono y marcó el número del laboratorio Lincoln. Llamó al director y dijo exactamente lo que
Taylor le había pedido que dijera. Fue una conversación breve pero, por lo que Taylor pudo ver, Herzfeld no
encontró resistencia. Herzfeld colgó, sonrió a Taylor y dijo: “Bueno, está bien. Veremos que pasa." Dos semanas
después, Roberts aceptó el trabajo.
Larry Roberts tenía veintinueve años cuando entró en el Pentágono como el nuevo recluta de la ARPA. Se adaptó
rápidamente y su aversión por el tiempo libre pronto se volvió legendaria.
En unas pocas semanas, había memorizado el lugar, uno de los edificios más grandes y laberínticos del
mundo. Moverse por el edificio era complicado por el hecho de que ciertos pasillos estaban bloqueados como
áreas clasificadas. Roberts consiguió un cronómetro y comenzó a cronometrar varias rutas hacia sus destinos
frecuentes. La "Ruta de Larry" pronto se conoció comúnmente como la distancia más rápida entre dos puntos del
Pentágono.
Incluso antes de su primer día en ARPA, Roberts tenía un esquema rudimentario de la red informática. Luego, y
durante los años siguientes, a medida que el proyecto crecía, Roberts dibujó meticulosos diagramas de red,
esbozando dónde debían ir las líneas de datos y el número de saltos entre nodos. En papel de calco y bloc
de cuadrilla, creó cientos de bocetos conceptuales y lógicos como estos:
(Más tarde, una vez que el proyecto estuvo en marcha, Roberts concertó con Howard Frank, un experto
en el campo de la topología de redes, la realización de análisis por computadora sobre cómo diseñar la red
de la manera más rentable. Aun así, durante años Roberts Tenía el diseño de la red y los detalles
técnicos que la definían, claramente representados dentro de su cabeza.)
Ya se sabía mucho sobre cómo construir complicadas redes de comunicaciones para transportar voz,
sonido y otras señales más elementales. AT&T, por supuesto, tenía hegemonía absoluta en lo que
respecta a la red telefónica. Pero la transmisión sistemática de información es anterior a Ma Bell en al
menos unos miles de años. Los sistemas de mensajería se remontan al menos al reinado del rey egipcio
Sesostris I, hace casi cuatro mil años. El primer sistema de retransmisión, en el que se pasaba un mensaje
de un puesto de guardia a otro, surgió en el año 650 a.C. Durante cientos de años después, la invención
fue impulsada por la necesidad de una mayor velocidad en la transmisión de mensajes de un lugar a otro.
Avanzó entre palomas, gritos, banderas codificadas, espejos, faroles, antorchas y balizas.
Luego, en 1793, las primeras noticias se intercambiaron utilizando semáforos: paletas giratorias en una
torre que parecía una persona sosteniendo banderas de señales con los brazos extendidos.
A mediados del siglo XIX, las redes telegráficas dependían de la electricidad y Western Union Telegraph
Company había comenzado a cubrir los Estados Unidos con una red de cables para transmitir mensajes en
forma de pulsos eléctricos. El telégrafo fue un clásico temprano.
ejemplo de lo que se llama una “red de almacenamiento y reenvío”. Debido a las pérdidas eléctricas, las señales
tuvieron que transmitirse a través de una secuencia de estaciones repetidoras. Al principio, los mensajes
que llegaban a las centrales de conmutación se transcribían a mano y se reenviaban mediante código Morse
a la siguiente estación. Más tarde, los mensajes que llegaban se almacenaban automáticamente en cintas de
papel mecanografiadas hasta que un operador podía volver a escribir el mensaje para el siguiente tramo. En 1903,
los mensajes que llegaban se codificaban en un trozo de cinta de papel como una serie de pequeños agujeros, y la
cinta rota se colgaba de un gancho. Los empleados tomaban las cintas de los ganchos y las pasaban por un lector
de cintas que las reenviaba automáticamente mediante código Morse.
A mediados del siglo XX, después de que el teléfono había suplantado al telégrafo como principal medio de
comunicación, la American Telephone and Telegraph Company tenía un monopolio completo, aunque
estrictamente regulado, de las comunicaciones de larga distancia dentro de los Estados Unidos. La empresa
fue tenaz en su fortaleza tanto en el servicio telefónico como en el equipo que hizo posible dicho servicio.
Se prohibió conectar equipos extraños (que no sean Bell) a las líneas Bell debido a que los dispositivos extraños
podrían dañar todo el sistema telefónico. Todo lo agregado al sistema tenía que funcionar con el equipo existente.
A principios de la década de 1950, una empresa comenzó a fabricar un dispositivo llamado HushAPhone,
una cubierta de plástico para boquilla diseñada para permitir que quien llama hablara por teléfono sin ser escuchado.
AT&T logró que la Comisión Federal de Comunicaciones prohibiera el dispositivo después de presentar testigos
expertos que describieron cómo el HushAPhone dañó el sistema telefónico al reducir la calidad del teléfono. En
otro ejemplo del celo de AT&T, la compañía demandó a una funeraria del Medio Oeste que regalaba cubiertas
de plástico para guías telefónicas. AT&T argumentó que una cubierta de plástico de la guía telefónica oscurecía
el anuncio en la portada de las Páginas Amarillas y reducía el valor de la publicidad paga, ingresos que ayudaron
a reducir el costo del servicio telefónico.
Casi no había forma de incorporar una nueva tecnología radical al Bell System para que coexistiera con la antigua.
No fue hasta 1968, cuando la FCC permitió el uso de Carterfone (un dispositivo para conectar radios privadas de
dos vías con el sistema telefónico) que se aflojó el control implacable de AT&T sobre el sistema de
telecomunicaciones del país. No es sorprendente, entonces, que a principios de la década de 1960, cuando ARPA
comenzó a explorar una forma completamente nueva de transmitir información, AT&T no quisiera
participar.
Invenciones coincidentes
Así como los seres vivos evolucionan a través de un proceso de mutación y selección natural, las ideas en la ciencia
y sus aplicaciones en la tecnología hacen lo mismo. La evolución en la ciencia, como en la naturaleza (normalmente
una secuencia gradual de cambios), ocasionalmente da un salto revolucionario que rompe con el curso del
desarrollo. Nuevas ideas surgen simultáneamente pero de forma independiente. Y así lo hicieron cuando llegó
el momento de inventar una nueva forma de transmitir información.
A principios de la década de 1960, antes de que Larry Roberts se pusiera siquiera a trabajar en la creación de una
nueva red informática, otros dos investigadores, Paul Baran y Donald Davies, completamente desconocidos entre sí
y que trabajaban en continentes separados para alcanzar objetivos diferentes, llegaron prácticamente a la solución.
misma idea revolucionaria para un nuevo tipo de red de comunicaciones. La realización de sus
conceptos llegó a conocerse como conmutación de paquetes.
Paul Baran era un inmigrante de buen humor procedente de Europa del Este. Nació en 1926, en la
entonces Polonia. Sus padres buscaron refugio en Estados Unidos dos años después, tras una
larga espera para obtener los documentos de inmigración. La familia llegó a Boston, donde el
padre de Paul fue a trabajar en una fábrica de zapatos, y luego se instaló en Filadelfia, donde abrió
una pequeña tienda de comestibles. Cuando era niño, Paul entregaba la compra a su padre utilizando
un pequeño carrito rojo. Una vez, cuando tenía cinco años, le preguntó a su madre si eran ricos o
pobres. “Somos pobres”, respondió. Más tarde le hizo la misma pregunta a su padre. “Somos ricos”,
respondió el Baran mayor, planteando a su hijo el primero de muchos enigmas existenciales de este
tipo en su vida.
Paul finalmente asistió a la escuela, a dos pasos de tranvía de su casa, en el Instituto de

Tecnología de Drexel, que más tarde se convirtió en la Universidad de Drexel. Lo desanimó el
énfasis de la escuela en esos días en la resolución rápida de problemas numéricos: dos errores
aritméticos triviales en una prueba (una carrera contra el reloj), y fallaste, independientemente de si
entendías o no fundamentalmente los problemas. En ese momento, Drexel estaba tratando de
crearse una reputación como un lugar duro y sensato y se enorgullecía de su alta tasa de
deserción escolar. Los instructores de Drexel dijeron a sus ingenieros en ciernes que los empleadores
sólo querían a aquellos que pudieran calcular rápida y correctamente. Para su consternación, Baran
vio a muchos amigos brillantes e imaginativos expulsados por la “actitud machista” de la escuela
hacia las matemáticas. Pero aguantó y en 1949 obtuvo un título en ingeniería eléctrica.
Los trabajos eran escasos, por lo que aceptó la primera oferta que le llegó, de EckertMauchly
Computer Corporation. En su capacidad relativamente mundana de técnico, probó piezas para
tubos de radio y diodos de germanio en la primera computadora comercial: la UNIVAC. Baran pronto
se casó y él y su esposa se mudaron a Los Ángeles, donde aceptó un trabajo en Hughes
Aircraft trabajando en radar. sistemas de procesamiento de datos. Tomó clases nocturnas en
UCLA sobre computadoras y transistores, y en 1959 obtuvo una maestría en ingeniería.
Baran dejó Hughes a finales de 1959 para unirse al departamento de informática de la

división de matemáticas de RAND Corporation mientras continuaba tomando clases en UCLA.
Baran se mostró ambivalente, pero su asesor en UCLA, Jerry Estrin, lo instó a continuar sus
estudios para obtener un doctorado. Pronto, una intensa agenda de viajes lo obligó a faltar a clases.
Pero finalmente fue la intervención divina, dijo, la que provocó su decisión de abandonar el trabajo
doctoral. “Un día estaba conduciendo hacia UCLA desde RAND y no pude encontrar ni un solo
lugar para estacionar en toda UCLA ni en toda la ciudad adyacente de Westwood”.
recordó Barán. “En ese instante llegué a la conclusión de que era la voluntad de Dios que
dejara la escuela. ¿Por qué si no habría considerado necesario llenar todos los estacionamientos en
ese instante exacto?
Poco después de llegar a RAND, Baran desarrolló un interés en la capacidad de supervivencia de

los sistemas de comunicaciones bajo un ataque nuclear. Lo motivaron principalmente las
crecientes tensiones de la guerra fría, no los desafíos de ingeniería involucrados. Tanto Estados
Unidos como la Unión Soviética estaban en el proceso de construir arsenales de misiles balísticos
nucleares de gatillo instantáneo. En 1960, la creciente carrera armamentista entre Estados Unidos
y la Unión Soviética aumentó la amenaza del fin del mundo (la aniquilación nuclear) sobre la vida cotidiana
en ambos países.
Baran sabía, como todos los que conocían las armas nucleares y la tecnología de las comunicaciones, que los
primeros sistemas de mando y control para el lanzamiento de misiles eran peligrosamente frágiles.
Para los líderes militares, la parte de "comando" de la ecuación significaba tener todas las armas, personas y
máquinas del ejército moderno a su disposición y poder "conseguir que hagan lo que usted quiere que hagan",
como explicó un analista. . "Control" significaba todo lo contrario: "conseguir que no hagan lo que usted no
quiere que hagan". La amenaza de que un país u otro tuviera sus sistemas de mando destruidos en un
ataque y quedara incapaz de lanzar un ataque defensivo o de represalia dio lugar a lo que Baran describió
como “una peligrosa tentación para cualquiera de las partes de malinterpretar las acciones de la otra y disparar
primero."
Según lo vieron los estrategas de RAND, era una condición necesaria que los sistemas de comunicaciones de
las armas estratégicas pudieran sobrevivir a un ataque, para que la capacidad de represalia del país aún
pudiera funcionar. En ese momento, las redes de comunicaciones de larga distancia del país eran
extremadamente vulnerables e incapaces de resistir un ataque nuclear. Sin embargo, la capacidad del presidente
para solicitar o suspender el lanzamiento de misiles estadounidenses (llamados “comunicaciones
esenciales mínimas”) dependía en gran medida de los vulnerables sistemas de comunicaciones de
la nación. Así que Baran sintió que trabajar en el problema de construir una infraestructura de comunicaciones
más estable (es decir, una red más resistente y robusta) era el trabajo más importante que podía hacer.
Baran no fue el primero en RAND en pensar en este problema. De hecho, lo habitual en RAND era estudiar este
tipo de cosas. RAND se creó en 1946 para preservar la capacidad de investigación de operaciones del país
desarrollada durante la Segunda Guerra Mundial. La mayoría de sus contratos provinieron de la Fuerza Aérea. El
problema de la supervivencia del sistema de comunicaciones era algo en lo que estaba trabajando la
división de comunicaciones de RAND, pero con un éxito limitado. Baran fue uno de los primeros en
determinar, al menos a nivel teórico, que el problema tenía solución. Y fue sin duda el primero en ver que la
forma de solucionarlo era aplicando la tecnología informática digital.
Pocos de los expertos en electrónica de otros departamentos de RAND sabían mucho sobre el campo
emergente de la tecnología informática digital, y aún menos parecían interesados. Baran recordó lo diferente
que era su propio pensamiento del de ellos: “Muchas de las cosas que creía posibles tenderían a parecer una
completa tontería o poco prácticas, dependiendo de la generosidad de espíritu de quienes crecieron en un
mundo anterior”. Y no fueron sólo sus colegas de RAND quienes miraron con escepticismo el pensamiento
de Baran. La comunidad de comunicaciones tradicionales en general rápidamente descartó sus ideas
por considerarlas no sólo picantes, sino también insostenibles.
En lugar de rehuir, Baran simplemente se sumergió más profundamente en su trabajo. RAND

permitió a los investigadores suficiente libertad para perseguir sus propias ideas y, a finales de 1960, el
interés y el conocimiento de las redes de Baran se habían convertido en un pequeño proyecto independiente.
Convencido del mérito de sus ideas, se embarcó en escribir una serie de artículos técnicos completos para
responder a las objeciones planteadas anteriormente y explicar cada vez más
detalla lo que estaba proponiendo. El trabajo, como explicó años después, no se realizó por curiosidad
intelectual ni por deseo de publicar. "Se hizo en respuesta a la situación más peligrosa que jamás
haya existido", dijo.
En el Pentágono, Baran encontró planificadores que pensaban en términos impasibles sobre los
escenarios posteriores al ataque y hacían estimaciones cuantitativas de la destrucción que resultaría
de un ataque con misiles balísticos nucleares soviéticos. “Existe la posibilidad de una guerra, pero se
puede hacer mucho para minimizar las consecuencias”, escribió Baran. “Si la guerra no significa el fin de
la tierra en blanco y negro, entonces debemos hacer aquellas cosas que hagan que el tono de gris sea lo
más claro posible: planificar ahora para minimizar la destrucción potencial y hacer todas esas cosas
necesarias para permitir a los supervivientes del holocausto sacudir sus cenizas y reconstruir la
economía rápidamente”.
El primer artículo de Baran reveló destellos de sus nacientes y revolucionarias ideas sobre la teoría y la
estructura de las redes de comunicaciones. Había llegado tentativamente a la idea de que una red de
datos podría hacerse más robusta y confiable introduciendo niveles más altos de redundancia. Las
computadoras fueron clave. Independientemente de Licklider y otros miembros de la vanguardia
informática, Baran vio mucho más allá de la informática convencional, hacia el futuro de las
tecnologías digitales y la simbiosis entre humanos y máquinas.
Baran estaba trabajando en el problema de cómo construir estructuras de comunicaciones cuyos

componentes supervivientes pudieran seguir funcionando como una entidad cohesiva después de que
otras piezas fueran destruidas. Mantuvo largas conversaciones con Warren McCulloch, un eminente
psiquiatra del Laboratorio de Investigación en Electrónica del MIT. Discutieron el cerebro, sus
estructuras de redes neuronales y lo que sucede cuando una parte está enferma, en particular
cómo las funciones cerebrales a veces pueden recuperarse evitando una región disfuncional. "Bueno,
caramba, ya sabes", recordó haber pensado Baran, "el cerebro parece tener algunas de las propiedades
que uno necesitaría para una estabilidad real". Le pareció significativo que las funciones cerebrales no
dependieran de un conjunto único y exclusivo de células. Esta es la razón por la que las células
dañadas pueden evitarse a medida que las redes neuronales se recrean a través de nuevas vías en el cerebro.
La noción de dividir una única estructura vulnerable de gran tamaño en muchas partes, como
mecanismo de defensa, puede verse en muchas otras aplicaciones. El concepto no es del todo diferente a
la idea de estructuras segmentadas o compartimentadas utilizadas en los cascos de barcos modernos
o en los camiones cisterna de gasolina. Si sólo se rompen una o dos áreas de la piel, sólo una sección de
la estructura general pierde su utilidad, no toda. Algunos grupos terroristas y operaciones de
espionaje emplean un tipo similar de organización compartimentada para frustrar a las autoridades, que
podrían eliminar una célula sin poner en peligro a todo el grupo.
En teoría, podría ser posible configurar una red con numerosas conexiones redundantes, y
“comenzaríamos a obtener estructuras parecidas a redes neuronales”, dijo Baran.
Pero había una limitación técnica, ya que todas las señales de la red telefónica eran analógicas. El
plan de conmutación telefónica prohibía conectar más de cinco enlaces en tándem, porque la
calidad de la señal se deterioraba rápidamente con el aumento del número de enlaces en tándem.
En cada enlace conmutado, la señal se distorsionaría ligeramente y la calidad se degradaría
progresivamente. Esto es similar a lo que sucede cuando uno hace
copias de copias de cintas de audio. Con cada nueva generación, la calidad se deteriora y eventualmente
llega a distorsionarse irremediablemente.
A diferencia de los sistemas analógicos, las tecnologías digitales esencialmente convierten información de todo tipo,
incluidos sonido e imagen, en un conjunto de unos y ceros. La información digitalizada se puede almacenar de
manera eficiente y replicar un número ilimitado de veces dentro de los circuitos de un dispositivo digital,
reproduciendo los datos con una precisión casi perfecta. En un contexto de comunicaciones, la información codificada
digitalmente puede pasar de un conmutador a otro con mucha menos degradación que en la transmisión
analógica.
Como escribió Baran en su artículo inicial: “El momento para pensar así es particularmente apropiado
ahora, porque apenas estamos comenzando a diseñar diseños para el sistema de transmisión de datos
digitales del futuro”. Los tecnólogos podrían imaginar de manera realista nuevos sistemas en los que las
computadoras se comunicarían entre sí, permitiendo una red con suficientes enlaces conectados
secuencialmente para crear niveles adecuados de redundancia. Estas estructuras interconectadas se parecen
(de manera muy modesta) a los asombrosamente complicados miles de millones de conexiones entre las
neuronas del cerebro. Y las computadoras digitales ofrecían velocidad.
Los interruptores telefónicos mecánicos de la época tardaban veinte o treinta segundos en establecer una única
conexión de larga distancia a través de una línea telefónica típica.
Al hablar con varios comandantes militares, Baran descubrió que una comunicación adecuada en tiempos de guerra
requiere la transmisión de muchos más datos que las “comunicaciones mínimas esenciales” conceptuales. Era difícil
saber exactamente cuánto más, por lo que Baran cambió el objetivo a una red capaz de soportar casi cualquier volumen
de tráfico imaginable.
La configuración teórica básica de la red de Baran era tan simple como dramáticamente diferente y nueva. Las
redes telefónicas siempre se han construido utilizando puntos de conmutación centrales. Las más vulnerables
son aquellas redes centralizadas en las que todos los caminos conducen a un único centro neurálgico. El otro
diseño común es una red descentralizada con varios centros neurálgicos principales alrededor de los cuales se
agrupan los enlaces, con unas pocas líneas largas que conectan entre los grupos; Básicamente, así es como se ve
todavía hoy en términos esquemáticos el sistema telefónico de larga distancia.
La idea de Baran constituyó un tercer enfoque para el diseño de redes. Llamó a la suya una red distribuida. Evite
tener un conmutador central de comunicaciones, dijo, y construya una red compuesta por muchos nodos, cada
uno de ellos conectado de forma redundante a su vecino. Su diagrama original mostraba una red de nodos
interconectados que se asemejaban a una red distorsionada, o pez.
neto.
La pregunta seguía siendo: ¿cuánta redundancia en las interconexiones entre nodos vecinos se
necesitaría para la supervivencia? “Nivel de redundancia” era el término de Baran para referirse al grado
de conectividad entre nodos de la red. Se decía que una red distribuida con el número mínimo absoluto de
enlaces necesarios para conectar cada nodo tenía un nivel de redundancia de 1 y se consideraba
extremadamente vulnerable. Baran realizó numerosas simulaciones para determinar la probabilidad
de supervivencia de la red distribuida en una variedad de escenarios de ataque. Concluyó que un nivel de
redundancia tan bajo como 3 o 4—
cada nodo conectado a otros tres o cuatro nodos proporcionaría un nivel excepcionalmente alto de robustez
y confiabilidad. "Sólo un nivel de redundancia de quizás tres o cuatro permitiría una red casi tan robusta como
el límite teórico", afirmó. Incluso después de un ataque nuclear, debería ser posible encontrar y utilizar
algún camino a través de la red restante.
"Ese fue un hallazgo muy afortunado porque significó que no necesitaríamos comprar una gran cantidad
de redundancia para construir redes con capacidad de supervivencia", dijo Baran. Incluso los enlaces
poco fiables y de bajo coste serían suficientes siempre que hubiera al menos tres veces el número
mínimo de ellos.
La segunda gran idea de Baran fue aún más revolucionaria: fracturar también los mensajes. Al dividir
cada mensaje en partes, se podía inundar la red con lo que él llamaba “bloques de mensajes”, todos
corriendo por diferentes caminos hacia su destino. A su llegada, una computadora receptora volvería a
ensamblar los bits del mensaje en un formato legible.
Conceptualmente, se trataba de un enfoque tomado más del mundo de los transportistas de mercancías que
de los expertos en comunicaciones. Piensa en cada mensaje como si fuera una casa grande y
pregúntate cómo trasladarías esa casa al otro lado del país, desde, por ejemplo, Boston a Los Ángeles.
En teoría, se podría mover toda la estructura de una sola pieza. Los encargados de la mudanza lo hacen
en distancias más cortas todo el tiempo, de forma lenta y cuidadosa. Sin embargo, es más eficiente
desmontar la estructura si es posible, cargar las piezas en camiones y conducir esos camiones por el
sistema de carreteras interestatales del país, otro tipo de red distribuida.
No todos los camiones tomarán la misma ruta; algunos conductores pueden pasar por Chicago y otros
por Nashville. Si un conductor se entera de que la carretera está en mal estado en Kansas City, por
ejemplo, puede tomar una ruta alternativa. Siempre y cuando cada conductor tenga instrucciones claras
que le indiquen dónde entregar su carga y se le indique que tome el camino más rápido que pueda encontrar,
Lo más probable es que todas las piezas lleguen a su destino en Los Ángeles y la casa pueda volver a montarse en un
nuevo sitio. En algunos casos, el último camión en salir de Boston puede ser el primero en llegar a Los Ángeles, pero si
cada pieza de la casa lleva una etiqueta que indica su lugar en la estructura general, el orden de llegada no importa.
Los reconstructores pueden encontrar las piezas adecuadas y ensamblarlas en los lugares correctos.
En el modelo de Baran, estas piezas eran lo que él llamaba “bloques de mensajes”, y debían ser de cierto tamaño, del
mismo modo que (en la analogía del camión) la mayoría de los vehículos con remolque comparten la misma
configuración. La ventaja de la técnica de mensajería por paquetes se obtuvo principalmente en una red
distribuida que ofrecía muchas rutas diferentes.
La innovación de Baran también proporcionó una solución muy necesaria a la naturaleza "rápida" de las comunicaciones
de datos. En ese momento, todas las redes de comunicaciones tenían conmutación de circuitos, lo que significaba que
se reservaba una línea de comunicaciones para una llamada a la vez y se mantenía abierta durante esa sesión. Una
llamada telefónica entre adolescentes bloqueará la línea mientras se compadezcan de sus novios y cuenten historias
sobre sus rivales. Incluso durante las pausas en la conversación, la línea permanece dedicada a esa conversación
hasta que termina.
Y técnicamente esto tiene mucho sentido, ya que las personas tienden a mantener un flujo de conversación bastante
constante durante una llamada telefónica.
Pero un flujo de datos es diferente. Por lo general, sale en ráfagas cortas seguidas de pausas vacías que dejan la
línea inactiva gran parte del tiempo, desperdiciando su “ancho de banda” o capacidad.
A un conocido informático le gustaba poner el ejemplo de una panadería con un solo empleado en el mostrador, donde
los clientes suelen llegar en ráfagas aleatorias. El dependiente tiene que permanecer en el mostrador durante
todo el día, a veces ocupado, a veces inactivo. En el contexto de la red de comunicaciones de datos, es una
forma muy ineficiente de utilizar una conexión de larga distancia.
Entonces, sería mucho más rentable enviar datos en “bloques” y asignar ancho de banda de tal manera que diferentes
mensajes pudieran compartir la línea. Un mensaje se dividiría en bloques específicos, que luego se enviarían
individualmente a través de la red a través de múltiples ubicaciones y se volverían a ensamblar en su destino.
Debido a que había múltiples caminos por los cuales se podían transmitir los diferentes bloques, podían llegar fuera
de secuencia, lo que significaba que una vez que llegaba un mensaje completo, por desordenado que fuera, era
necesario volver a ensamblarlo en el orden correcto. Por tanto, cada bloque debería contener información que identifique
la parte del mensaje a la que pertenece.
Lo que Baran imaginó fue una red de conmutadores o nodos no tripulados (computadoras independientes,
esencialmente) que enrutaran mensajes empleando lo que llamó una “política de autoaprendizaje en cada nodo,
sin necesidad de un punto de control central, y posiblemente vulnerable”. .” Se le ocurrió un plan para enviar información
de un lado a otro al que llamó “enrutamiento de la papa caliente”, que era esencialmente un sistema rápido de
almacenamiento y reenvío que funcionaba casi instantáneamente, en contraste con el antiguo procedimiento de
teletipo postit y reenvío. .
En el modelo de Baran, cada nodo de conmutación contenía una tabla de enrutamiento que actuaba como una especie
de coordinador o despachador de transporte. La tabla de enrutamiento en cada nodo reflejaba cuántos saltos o
enlaces se requerían para llegar a todos los demás nodos de la red. La mesa
indicaba las mejores rutas a tomar y se actualizaba constantemente con información sobre nodos vecinos,
distancias y retrasos, de manera muy similar a los despachadores o conductores de camiones que usan sus
radios CB para mantenerse informados unos a otros sobre accidentes, trabajos de construcción, desvíos y controles
de velocidad. La actualización continua de las tablas también se conoce como enrutamiento “adaptativo” o
“dinámico”.
Como sugiere el término "papa caliente", tan pronto como un bloque de mensajes ingresa a un nodo, es arrojado
nuevamente por la puerta lo más rápido posible. Si la mejor ruta de salida estaba ocupada (o destruida en
pedazos), el bloque de mensajes se enviaba automáticamente por la siguiente mejor ruta. Si ese enlace estaba
ocupado o no estaba, seguía la siguiente mejor ruta, y así sucesivamente. Y si se agotaran las opciones,
los datos podrían incluso enviarse de vuelta al nodo desde el que se originaron.
Baran, el inventor del plan, también se convirtió en su principal cabildero. Esperaba persuadir a AT&T de sus
ventajas. Pero no fue fácil. Descubrió que convencer a algunas personas de comunicación dentro de
RAND de la viabilidad de sus ideas ya era bastante difícil.
Estos conceptos eran totalmente desconocidos en los círculos tradicionales de las telecomunicaciones.
Finalmente se ganó el apoyo de sus colegas. Pero ganarse a la gerencia de AT&T, a quien se recurriría si se
construyera dicha red, resultó casi imposible.
La primera tarea de Baran fue demostrar que el sistema de comunicaciones de larga distancia de la nación
(que constaba casi exclusivamente de líneas de AT&T) fallaría en un primer ataque soviético. Los funcionarios de
AT&T no sólo se negaron a creer esto sino que también se negaron a permitir que RAND usara sus mapas
de circuitos de larga distancia. RAND recurrió al uso de un conjunto robado de mapas de AT&T Long Lines para
analizar la vulnerabilidad del sistema telefónico.
A pesar de la vulnerabilidad, la idea de dividir los datos en bloques de mensajes y enviar cada bloque para que
encuentre su propio camino a través de una matriz de líneas telefónicas les pareció totalmente absurda a los
miembros del personal de AT&T. Su mundo era un lugar donde las comunicaciones se enviaban como un flujo
de señales por una tubería. Enviar datos en paquetes pequeños parecía tan lógico como enviar petróleo por un
oleoducto, una taza a la vez.
Los funcionarios de AT&T concluyeron que Baran no tenía ni idea de cómo funcionaba el sistema telefónico. "Su
actitud era que lo sabían todo y que nadie fuera del Bell System sabía nada", dijo Baran. “Y alguien desde
fuera no podría comprender ni apreciar la complejidad del sistema. Entonces aquí viene un idiota y habla
de algo muy simple, que obviamente no entiende cómo funciona el sistema”.
La respuesta de AT&T fue educar. La empresa inició una serie de seminarios sobre telefonía, dirigidos a un
pequeño grupo de personas externas, incluido Baran. Las clases duraron varias semanas. "Se necesitaron
noventa y cuatro oradores distintos para describir todo el sistema, ya que ningún individuo parecía
saber más que una parte del sistema", dijo Baran. “Probablemente su mayor decepción fue que después de
todo esto, dijeron: '¿Ahora ves por qué no puede funcionar?' Y yo dije: 'No'”.
Con la excepción de unos pocos partidarios de Bell Laboratories que entendían la tecnología digital, AT&T
siguió resistiéndose a la idea. Los escépticos más abiertos eran algunos de los técnicos más veteranos de AT&T.
“Después de escuchar el estribillo melódico de
'tonterías' con bastante frecuencia”, recuerda Baran, “me sentí motivado a irme y escribir una serie de
memorandos detallados, para demostrar, por ejemplo, que eran posibles algoritmos que permitieran que
un mensaje corto contuviera toda la información que necesitaba para encontrar su propio camino a
través de la red”. Con cada objeción respondida, se planteaba otra y había que redactar otra parte del
informe. Cuando Baran respondió a todas las inquietudes planteadas por las comunidades de defensa,
comunicaciones e informática, habían pasado casi cuatro años y sus volúmenes sumaban once.
A pesar de la intransigencia de AT&T, Baran creía que estaba involucrado en lo que llamó un “desacuerdo
honesto” con funcionarios de la compañía telefónica. “La gente de la sede de AT&T siempre optó por creer
que sus acciones eran en beneficio de la 'red', que por definición era lo mejor para el país”, dijo.
En 1965, cinco años después de embarcarse en el proyecto, Baran contaba con el apoyo total de RAND, y
en agosto RAND envió una recomendación formal a la Fuerza Aérea para que se construyera una red de
conmutación distribuida, primero como un programa de investigación y desarrollo y luego como un
. de supervivencia. . Un
programa. Sistema totalmente operativo: “La necesidad de un sistema
sistema de comunicaciones flexible y de usuario a usuario es de suma importancia. No conocemos ninguna
propuesta de sistema alternativo comparable para lograr esta capacidad, y creemos que la Fuerza Aérea
debe actuar rápidamente para implementar el programa de investigación y desarrollo propuesto en
este documento”.
La Fuerza Aérea estuvo de acuerdo. Ahora los únicos que resistían eran los funcionarios de AT&T.
La Fuerza Aérea dijo a AT&T que pagaría a la compañía telefónica para construir y mantener la red. Pero
la compañía telefónica no se dejó convencer.
La Fuerza Aérea, decidida a no dejar que el plan muriera en la mesa de dibujo, decidió que debía proceder
sin la cooperación de AT&T. Pero el Pentágono decidió poner a la recién formada Agencia de Comunicaciones
de Defensa (DCA), y no a la Fuerza Aérea, a cargo de construir la red. Baran no imaginaba más que
problemas. La agencia estaba dirigida por un grupo de oficiales de comunicación anticuados de cada uno de
los distintos servicios, sin experiencia en tecnología digital. Para empeorar las cosas, el entusiasmo del
DCA por el proyecto estuvo a la par de la respuesta de AT&T. “Así que les dije a mis amigos en el
Pentágono que abortaran todo este programa, porque no lo harían bien”, recordó Baran. “Habría sido un
desperdicio de dinero del gobierno y habría hecho retroceder las cosas. El DCA lo arruinaría y entonces
nadie más podría intentarlo, dado el intento fallido que consta en los libros”.
Baran consideró que era mejor esperar hasta que “apareciera una organización competente”. Y dicho
esto, después de cinco años de lucha, Paul Baran centró su atención en otras cosas. Fue, en gran medida,
una visita al “¿Somos ricos o somos pobres?” pregunta que había planteado décadas antes a sus padres,
cuyas respuestas marcadamente contrastantes le ayudaron a comprender que la mayoría de las
cosas en la vida son una cuestión de perspectiva.
En Londres, en el otoño de 1965, justo después de que Baran detuviera el trabajo en su proyecto, Donald
Watts Davies, físico de cuarenta y un años del Laboratorio Nacional de Física Británico
(NPL), escribió la primera de varias notas personales exponiendo algunas ideas que estaba jugando
con una nueva red informática muy parecida a la de Baran. Envió su conjunto de notas a algunas
personas interesadas, pero (seguro que encontraría una fuerte resistencia por parte de las autoridades a
cargo del monopolio del servicio telefónico de la Oficina de Correos británica) se guardó sus ideas para sí
mismo. Davies quería tiempo para validar sus conceptos. En la primavera siguiente, confiado en
que sus ideas eran acertadas, dio una conferencia pública en Londres en la que describió la noción de
enviar bloques cortos de datos (a los que llamó “paquetes”) a través de una red digital de
almacenamiento y reenvío. Cuando la reunión estaba terminando, un hombre del público se acercó a
Davies y le dijo que era del Ministerio de Defensa. Le contó a Davies acerca de un trabajo notablemente
similar que un hombre llamado Paul Baran había hecho circular en la comunidad de defensa
estadounidense. Davies nunca había oído hablar de Baran ni de sus estudios RAND.
Donald Davies era hijo de padres de clase trabajadora. Su padre, un empleado de una mina de carbón en
Gales, murió un año después del nacimiento de Donald y su hermana gemela. Su madre trasladó a su
joven familia a Portsmouth, un puerto naval británico, donde empezó a trabajar como dependienta en la
oficina de correos. Donald experimentó con la radio a una edad temprana y se interesó tempranamente por
la física. Aún no tenía catorce años cuando su madre trajo a casa un libro, algo que un ingeniero había
dejado en la oficina de correos, sobre telefonía. El volumen técnico describía la lógica y el diseño
de los sistemas de conmutación telefónica y “produjo horas de lectura fascinante”, recordó Davies
años después.
A Davies, un estudiante excepcional, se le ofrecieron becas para varias universidades. Para celebrar
a su estudiante estrella, su escuela declaró medio día feriado. “Durante un tiempo fui el chico más popular
de la escuela”, recuerda. Davies eligió el Imperial College de la Universidad de Londres y, cuando
tenía veintitrés años, ya había obtenido títulos en física y matemáticas. En 1947 se unió a un equipo de
científicos dirigido por el matemático Alan Turing en el Laboratorio Nacional de Física y Davies desempeñó
un papel destacado en la construcción de la computadora digital más rápida de Inglaterra en ese
momento, la Pilot ACE. En 1954, Davies ganó una beca para pasar un año en Estados Unidos; parte
de ese año estuvo en el MIT. Luego regresó a Inglaterra, ascendió rápidamente en la NPL y en 1966,
después de describir su trabajo pionero en conmutación de paquetes, fue nombrado jefe de la división de
informática.
La similitud técnica entre el trabajo de Davies y Baran fue sorprendente. No sólo sus ideas eran más o
menos paralelas en concepto, sino que, por coincidencia, incluso habían elegido el mismo tamaño de
paquete y velocidad de transmisión de datos. Independientemente, a Davies también se le ocurrió un
esquema de enrutamiento que era adaptable, como el de Baran, pero diferente en detalles.
Sólo había una diferencia importante en sus enfoques. La motivación que llevó a Davies a concebir una
red de conmutación de paquetes no tuvo nada que ver con las preocupaciones militares que habían
impulsado a Baran. Davies simplemente quería crear una nueva red de comunicaciones públicas.
Quería explotar las fortalezas técnicas que vio en las computadoras y conmutadores digitales, para
lograr una computación altamente interactiva y con gran capacidad de respuesta a largas distancias.
Una red de este tipo tendría mayor velocidad y eficiencia que los sistemas existentes.
A Davies le preocupaba que las redes de circuitos conmutados no se adaptaran bien a los
requisitos de las computadoras que interactuaban. Las características irregulares y en ráfagas del tráfico
de datos generado por computadora no encajaban bien con la capacidad uniforme del canal del teléfono.
sistema. Su principal motivación fue adaptar el diseño de la red a los nuevos tipos de tráfico de datos.
En lugar de realizar el tipo de estudios de redundancia y confiabilidad a los que Baran había dedicado tanto
tiempo, Davies se centró en resolver los detalles de la configuración de los bloques de datos. También previó la
necesidad de superar las diferencias en los lenguajes informáticos y los procedimientos operativos de las
máquinas (diferencias en hardware y software) que existirían en una gran red pública. Imaginó el día en que
alguien se sentaría frente a un tipo de computadora e interactuaría con una máquina de otro tipo en otro lugar.
Para cerrar la brecha entre los sistemas informáticos tan divergentes de la época, comenzó a delinear las
características de un dispositivo intermediario (una nueva computadora) que serviría como traductor,
ensamblando y desensamblando mensajes digitales para las otras máquinas.
La idea de dividir los mensajes en “paquetes” de datos uniformes, cada uno de la longitud de una línea de
texto típica, fue algo que se le ocurrió a Davies después de estudiar sistemas avanzados de tiempo compartido y
cómo asignaban el tiempo de procesamiento a múltiples usuarios. En un viaje a los Estados Unidos en 1965 había
observado el sistema de tiempo compartido Proyecto MAC del MIT. Unos meses más tarde, la NPL había
acogido en Londres a un grupo del MIT, incluido Larry Roberts, para seguir debatiendo sobre el tiempo compartido.
Fue en esas reuniones cuando a Davies se le ocurrió por primera vez la idea del paquete. A diferencia de la fría
reacción de AT&T hacia Baran, el establishment de telecomunicaciones británico abrazó
las ideas de Davies. Se le animó a buscar financiación para una red experimental en NPL.
Los sistemas de tiempo compartido ya habían resuelto el persistente problema del lento tiempo de respuesta en el
procesamiento por lotes al darle a cada usuario una porción del tiempo de procesamiento de la computadora.
Varias personas podrían estar ejecutando trabajos a la vez sin notar ningún retraso significativo en su trabajo.
De manera análoga, en una red de comunicaciones digitales, una computadora podría dividir los mensajes en
pequeños pedazos, o paquetes, verterlos en la tubería electrónica y permitir a los usuarios compartir la capacidad
total de la red. Davies, al igual que Baran, vio en la era digital la viabilidad de un nuevo tipo de red de
comunicaciones.
La elección de Davies de la palabra “paquete” fue muy deliberada. "Pensé que era importante tener una nueva
palabra para uno de los datos breves que viajaban por separado", explicó. "Esto haría que fuera más
fácil hablar de ellos". Había muchas otras posibilidades: bloque, unidad, sección, segmento, marco. “Me
encontré con la palabra paquete”, dijo, “en el sentido de paquete pequeño”. Antes de decidirse por la palabra, pidió
a dos lingüistas de un equipo de investigación de su laboratorio que confirmaran que había cognados en otros
idiomas. Cuando le informaron que era una buena elección, se decidió por ella. Conmutación de paquetes.
Era preciso, económico y muy británico. Y era mucho más agradable para el oído que el "cambio de bloque
de mensajes adaptativo distribuido" de Baran. Davies conoció a Baran por primera vez varios años
después. Le dijo a Baran que se había sentido completamente avergonzado al enterarse del trabajo de
Baran después de haber terminado el suyo, y luego agregó: "Bueno, es posible que hayas llegado primero,
pero yo tengo el nombre".
Mapeándolo
En diciembre de 1966, cuando Larry Roberts llegó al Pentágono, conocía a Donald Davies de su viaje a
Londres el año anterior, pero no sabía nada del trabajo posterior de Davies en conmutación de
paquetes. Y nunca había oído el nombre de Paul Baran.
Unos años antes, Roberts había decidido que la informática se estaba volviendo obsoleta y que todo lo
que valía la pena hacer dentro de una computadora ya se había hecho. Esto le había llegado
como una revelación en una conferencia celebrada en 1964 en Homestead, Virginia, donde Roberts,
Licklider y otros permanecieron despiertos hasta altas horas de la madrugada hablando sobre el
potencial de las redes informáticas. Roberts salió de la reunión decidido a comenzar
a trabajar en las comunicaciones entre computadoras.
Su primera oportunidad llegó un año después, cuando supervisó uno de los primeros experimentos reales
para unir máquinas dispares a largas distancias. En 1965, el psicólogo Tom Marill, que había estudiado
con Licklider y que también estaba fascinado por las computadoras, fundó una pequeña empresa de
tiempo compartido, Computer Corporation of America (CCA). Cuando el mayor inversor de Marill se
echó atrás en el último minuto, Marill buscó algún trabajo de I+D. Propuso a ARPA que llevara a cabo un
experimento de red vinculando la computadora TX2 de Lincoln al SDC Q32 en Santa Mónica.
Sin embargo, la empresa de Marill era tan pequeña que ARPA recomendó llevar a cabo su experimento
bajo los auspicios del Laboratorio Lincoln. A los funcionarios de Lincoln les gustó la idea y
pusieron a Larry Roberts a cargo de supervisar el proyecto.
El objetivo era claro. Como argumentó Marill en una carta a Roberts en 1965, la informática había
llegado a una situación desafortunada; Los proyectos de tiempo compartido estaban proliferando, pero no
había “un terreno común para el intercambio de programas, personal, experiencia o ideas”. Su impresión
de la comunidad informática era "la de una serie de proyectos esencialmente similares, cada uno de los
cuales iba en su propia dirección sin tener en cuenta a los demás". ¿Por qué desperdiciar recursos?
Hasta donde llegó, el experimento TX2 fue ambicioso. El enlace entre las dos computadoras
se realizó mediante un servicio especial fullduplex de cuatro hilos de Western Union (full duplex
proporciona transmisión simultánea en ambas direcciones entre dos puntos). A esto Marill adjuntó una
forma tosca de módem, que funcionaba a 2.000 bits por segundo, al que llamó marcador automático. Al
vincular directamente las máquinas, Marill solucionó el problema de las incompatibilidades entre
ellas. La idea era conectar las computadoras como un par de gemelos siameses, ejecutando programas
in situ. Aunque no transfirieron archivos de un lado a otro, el experimento permitió que las máquinas
se enviaran mensajes entre sí. Marill configuró un procedimiento para agrupar caracteres en mensajes,
enviarlos a través del enlace y verificar si los mensajes llegaban. Si no se recibió ningún acuse de recibo,
el mensaje se retransmitió. Marill se refirió al conjunto de procedimientos para enviar información de
un lado a otro como un “protocolo” de mensaje, lo que llevó a un colega a preguntar: “¿Por qué usa ese
término? Pensé que se refería a la diplomacia”.
En un informe de 1966 que resumía los resultados iniciales del experimento, Marill escribió que no
podía “prever ningún obstáculo que no se pueda esperar superar con una cantidad razonable de
diligencia”. A pesar de la diligencia, cuando Marill y Roberts conectaron las dos máquinas, los resultados
fueron mixtos. La conexión en sí funcionó según lo planeado. Pero el
La confiabilidad de la conexión y el tiempo de respuesta fueron, como los describiría Roberts varios
años después, simplemente pésimos.
Reunir dos computadoras diferentes era una cosa, pero el proyecto por el cual Roberts había
sido retirado de Lincoln para trabajar en ARPA era otro desafío mucho mayor. Interconectar una matriz
de máquinas, cada una con características distintas, sería sumamente complicado. Para lograrlo
probablemente sería necesario recurrir a todos los expertos que Roberts conocía en todas las áreas de
la informática y las comunicaciones.
Afortunadamente, el círculo de colegas de Roberts era amplio. Uno de sus mejores amigos del
Laboratorio Lincoln, con quien había trabajado en el TX2, era Leonard Kleinrock, un ingeniero
inteligente y ambicioso que había asistido al MIT con una beca completa. Si alguien influyó en las
primeras ideas de Roberts sobre las redes informáticas, ese fue Kleinrock.
La disertación de Kleinrock, propuesta ya en 1959, fue un importante trabajo teórico que describió
una serie de modelos analíticos de redes de comunicación. Y en 1961, mientras trabajaba con
Roberts, Kleinrock había publicado un informe en el MIT que analizaba el problema del flujo de datos
en las redes. Kleinrock también había trabajado en procedimientos de enrutamiento aleatorio
y tuvo algunas ideas iniciales sobre cómo dividir mensajes en bloques para un uso eficiente de los
canales de comunicación. Ahora Kleinrock estaba en UCLA y Roberts le otorgó un contrato ARPA para
establecer allí el Centro de Medición de Redes oficial, un laboratorio dedicado a pruebas de rendimiento
de redes.
La amistad entre Roberts y Kleinrock iba mucho más allá de los intereses profesionales que
compartían. Los acertijos eran un interés común. Los planes para hacer dinero eran otro. Cada uno
reforzó la apertura del otro a la aventura fiscal. Aquellos que pensaban que Roberts era todo
trabajo y nada de juego nunca lo habían visto en acción con sus amigos.
Roberts y Kleinrock eran jugadores de casino empedernidos. Roberts desarrolló un esquema de conteo
"altobajo" para el blackjack y se lo enseñó a Kleinrock. Nunca llegaron a la galería oficial de
contadores de cartas incluidos en la lista negra de pícaros, pero más de una vez fueron descubiertos
por detectives del casino y les pidieron que se fueran.
Y en otro episodio atrevido, Roberts y Kleinrock idearon un plan para sacar provecho de la física de la
ruleta. La idea era predecir, empleando leyes rudimentarias del movimiento, cuándo la pelota se
saldría de su trayectoria. Para ello, necesitaban saber la velocidad de la pelota, que viajaba en una
dirección, y la velocidad de la rueda, que viajaba en la otra. Decidieron construir una pequeña máquina
que hiciera las predicciones, pero necesitaban algunos datos. Entonces Roberts tomó una grabadora,
se puso un micrófono en la mano y le hizo un yeso que parecía que tenía la muñeca rota. Los dos
se sentaron a la mesa y Roberts colocó su mano junto al volante para registrar el sonido del pase del
balón, del que luego podrían extrapolar su velocidad. El trabajo de Kleinrock consistía en distraer al
jefe de sala jugando varias rondas de ruleta. "Todo funcionaba bien excepto una cosa", dijo Kleinrock.
“Empecé a ganar. Me llamó la atención. El jefe de sala mira y ve a este tipo con un brazo roto y
con la mano cerca de la ruleta, agarra el brazo de Larry y le dice: '¡Déjame ver tu brazo!'. Larry y
yo salimos rápidamente de allí".
•••
Roberts estuvo de acuerdo con Taylor en que un tiempo de respuesta rápido para la red era fundamental,
porque un tiempo de demora bajo en los mensajes era crucial para la interactividad. Cualquiera que haya
utilizado sistemas de tiempo compartido que transmitieran datos a través de líneas de comunicación
estándar sabía lo lentos que podían ser. Los datos viajaban hacia y desde la computadora principal a
velocidades terriblemente lentas, de unos pocos cientos de bits por segundo. Recuperar o enviar incluso
una pequeña cantidad de información era un proceso que dejaba mucho tiempo para servirse una taza
de café, o incluso preparar una taza entera, mientras el módem se agitaba. Nadie quería una red lenta.
Durante una de las primeras reuniones del grupo informal de asesores que Roberts había reunido, alguien
golpeó la mesa con el puño y dijo: "Si esta red no puede darme una respuesta de un segundo,
no sirve de nada". De manera optimista, se incluyó en los requisitos un tiempo de respuesta de medio
segundo. La segunda prioridad, por supuesto, era la fiabilidad. Para que una red fuera eficaz, los
usuarios necesitaban total confianza en su capacidad para enviar datos de un lado a otro sin
problemas.
Otro motivo de consternación fue la cuestión de cómo se trazaría la red. Varias personas habían propuesto
que el intercambio de recursos se hiciera en una única computadora centralizada, ubicada, por ejemplo, en
Omaha, un lugar popular para los conmutadores telefónicos de larga distancia porque se encontraba
en el centro geográfico de la nación. Si la centralización tenía sentido para una red telefónica,
¿por qué no para una red informática? Quizás la red debería utilizar líneas telefónicas exclusivas (una
cuestión que aún no se había resuelto) lo que ayudaría a mantener los costos uniformes. Baran había
evitado un sistema centralizado porque eso aumentaba su vulnerabilidad. Roberts también se
opuso a un enfoque centralizado, pero decidió retrasar su decisión final hasta que pudiera abordar el
tema ante un grupo grande. Su oportunidad llegó pronto, en una reunión de los principales investigadores
de ARPA en Ann Arbor, Michigan, a principios de 1967.
Taylor había convocado la reunión y el tema principal de la agenda era el experimento de networking.
Roberts expuso su plan inicial. La idea, tal como él la describió, era conectar todas las computadoras de
tiempo compartido entre sí directamente, a través de líneas telefónicas de acceso telefónico.
Las funciones de red serían manejadas por las computadoras "anfitriones" en cada sitio. En otras palabras,
los hosts cumplirían una doble función, como computadoras de investigación y como enrutadores
de comunicaciones. La idea fue recibida con poco entusiasmo. Los habitantes de los lugares de acogida
propuestos preveían que los problemas no tendrían fin. Nadie quería renunciar a una porción desconocida
de valiosos recursos informáticos para administrar una red que no les entusiasmaba. Luego había docenas
de variaciones idiosincrásicas a las que enfrentarse, una de las cuales era el hecho de que cada máquina
hablaba un lenguaje sustancialmente diferente de las demás. Parecía casi imposible estandarizar un
conjunto de protocolos.
La reunión de Ann Arbor reveló la falta de entusiasmo, cuando no abiertamente hostilidad, hacia la
propuesta de Taylor y Roberts. Pocos investigadores principales de ARPA quisieron participar en el
experimento. Esta actitud fue especialmente pronunciada entre los investigadores de las universidades
de la costa este, que no veían ninguna razón para vincularse con campus universitarios del oeste. Eran
como la mujer de la clase alta de Beacon Hill a quien, cuando le dijeron que la larga distancia
El servicio telefónico a Texas estaba disponible, se hizo eco de la famosa frase de Thoreau:
"¿Pero qué tendría yo que decirle a alguien en Texas?"
Douglas Engelbart, científico informático del Instituto de Investigación de Stanford (SRI) en

1967, recordaba claramente la reunión. “Una de las primeras reacciones fue: 'Oh, diablos, aquí
tengo esta computadora de tiempo compartido y mis recursos ya son escasos'. Otra reacción fue:
'¿Por qué iba a dejar que mis estudiantes de posgrado se dejaran atrapar por algo como esto?'”
Sin embargo, rápidamente quedó claro cuán serio hablaba Roberts. Primero trató de disipar el
escepticismo sobre el intercambio de recursos señalando que todos tenían algo de interés en
su computadora que otros podrían querer. “Recuerdo que un tipo se volvió hacia el otro y le dijo:
'¿Qué tienes en tu computadora que pueda usar?'”, recordó Engelbart, “y el otro respondió: 'Bueno,
¿no lees mis informes?'” A nadie le cautivó la idea. "La gente pensaba: '¿Por qué necesitaría la
computadora de otra persona cuando lo tengo todo aquí?' recordó Jon Postel, entonces
estudiante de posgrado en UCLA. “¿Qué tendrían ellos que yo quisiera y qué tendría yo que
quisiera que los demás vieran?”
Un problema aún más difícil residía en superar las barreras de comunicación entre computadoras
dispares. ¿Cómo podría alguien programar el TX2, por ejemplo, para comunicarse con el
Sigma7 de UCLA o con la computadora del SRI? Las máquinas, sus sistemas operativos, sus
lenguajes de programación eran todos diferentes, y sólo Dios sabía qué otras
incongruencias los dividían.
Justo antes de que terminara la reunión, Wes Clark le pasó una nota a Roberts. Decía: "Tienes la
red al revés". Roberts estaba intrigado y quería saber más; sin embargo, la reunión se estaba
disolviendo y la gente ya se estaba yendo. Roberts, Taylor y algunos otros se reunieron alrededor
de Clark después, y un pequeño grupo decidió continuar la discusión durante el viaje de
regreso al aeropuerto. En el coche, Clark esbozó su idea: dejar los ordenadores host lo más
lejos posible y en su lugar insertar un ordenador pequeño entre cada ordenador host y la
red de líneas de transmisión. (Esto era, por coincidencia, precisamente lo que Davies había
llegado a la conclusión por separado en Inglaterra.)
Según lo explicó Clark, la solución era obvia: una subred con nodos pequeños e idénticos, todos
interconectados. La idea resolvió varios problemas. Imponía muchas menos exigencias a todos los
ordenadores centrales y, en consecuencia, menos exigencias a las personas a cargo de ellas. Las
computadoras más pequeñas que componen esta red interna hablarían todas el mismo idioma,
por supuesto, y ellas, no las computadoras host, estarían a cargo de todo el enrutamiento.
Además, las computadoras host tendrían que ajustar su idioma solo una vez.
para hablar con la subred. La idea de Clark no sólo tenía sentido desde el punto de vista técnico,
sino que también era una solución administrativa. ARPA podría tener toda la red bajo su
control directo y no preocuparse mucho por las características de cada host. Además, dotar a
cada sitio de su propio ordenador idéntico daría uniformidad al experimento.
Lo más curioso de la idea fue que a Clark se le ocurrió. No había prestado mucha atención
a los procedimientos en Ann Arbor. De hecho, todo esto le aburría un poco. Ya le había dicho a
Roberts en términos muy claros que no tenía ningún deseo de poner en la red su computadora
de la Universidad de Washington en St. Louis. Clark no era partidario del tiempo compartido, ni
siquiera del recurso compartido. Había estado trabajando en computadoras.
diseñado para uso individual y no vio ninguna razón particular para compartir sus instalaciones con
personas en una red. Pero cuando escuchó la discordia sobre cómo debería implementarse el
experimento ARPA, no pudo evitar arriesgarse a hacer una sugerencia. Quizás fue la antipatía de
Clark hacia el tiempo compartido lo que le permitió pensar en esto. Al asignar la tarea de enrutamiento a
las computadoras host, Roberts y otros esencialmente estaban agregando otra función de tiempo
compartido. La idea de Clark era ahorrarles a los hosts esa carga adicional y construir una red de
computadoras idénticas y no compartidas dedicadas al enrutamiento.
Durante el viaje al aeropuerto, la discusión se volvió animada. ¿No sería prohibitivamente costosa una
subred completa compuesta por computadoras individuales y frustraría el objetivo original de ahorrar
dinero? ¿Y quién, quería saber Roberts, creía Wes Clark que podría construir algo así? "Sólo hay una
persona en el país que puede hacer eso", respondió Clark.
"Corazón franco".
Larry Roberts conocía a Frank Heart. Los dos habían trabajado juntos en el Laboratorio Lincoln y
Roberts había compartido oficina con la esposa de Heart, Jane, programadora en Lincoln. Roberts y
Heart nunca habían trabajado juntos directamente, pero Roberts sabía que Heart era un ingeniero de
sistemas exigente. Era un experto en sistemas en tiempo real creados para cuando el mundo físico
exige una respuesta en fracciones de segundos, o al menos antes de que llegue el siguiente conjunto
de datos. Cualquier cosa que tuviera que ver con información entrante en un momento crítico, como los
datos de seguimiento por radar enviados al sistema SAGE y la información sísmica generada durante un
terremoto, se consideraba un sistema en tiempo real, y en la década de 1960 pocas personas
entendían los sistemas en tiempo real. tan bien como lo hizo Heart.
Roberts también sabía que Heart y Clark eran buenos amigos de Lincoln, donde Heart le había mostrado
a Clark los entresijos de la programación más de una década antes. Ahora, hasta donde Roberts
sabía, Heart estaba en Bolt Beranek and Newman en Cambridge, donde se había mudado en 1966
para trabajar en el uso de computadoras en medicina.
La red ARPA no fue concebida como un sistema en tiempo real, no en el mismo sentido de la palabra
en el que la entienden los verdaderos usuarios en tiempo real. (Todo lo que dura más de 10 a
20 milisegundos, el punto en el que los retrasos se vuelven humanamente perceptibles, no se
considera tiempo real). Estrictamente hablando, la red ARPA iba a ser un sistema de almacenamiento y reenvío.
Pero los datos entrarían y saldrían de los nodos tan rápidamente, y el tiempo de respuesta desde
una perspectiva humana sería tan rápido, que calificaría como un problema en tiempo real. El sistema
tendría que hacer frente a docenas de problemas que involucran eventos estrechamente
secuenciados y tiempos extremadamente ajustados. El estado de la red cambiaría constantemente, y
quien programara las computadoras que componían la subred propuesta por Clark necesitaría saber
cómo hacer que el sistema maneje los datos entrantes y salientes de manera confiable a velocidades muy rápidas.
Sin embargo, a pesar de la lógica de la recomendación de Clark, Roberts no podía simplemente

entregarle el trabajo a Heart. ARPA tuvo que respetar las reglas de contratación del gobierno. A lo
largo de los años, la mayoría de las propuestas que solicitaban financiación llegaron a ARPA sin ser
solicitadas. Pocas veces la agencia había solicitado propuestas. Pero éste era diferente. La idea de la red
se le ocurrió a la agencia internamente y en ese sentido era inusual. Además, debido a que la red
sería propiedad del gobierno controlada centralmente por ARPA y no
residir en un campus, digamos, o en una empresa de investigación, Roberts y otros decidieron que tenían
que enviar este proyecto a licitaciones competitivas.
Cuando regresó a Washington, Roberts escribió un memorando que describía la idea de Clark y lo
distribuyó a Kleinrock y otros. Llamó a las computadoras intermedias que controlarían la red
"procesadores de mensajes de interfaz" o IMP, que pronunció "diablillos". Debían realizar las
funciones de interconectar la red, enviar y recibir datos, verificar si hay errores, retransmitir en caso de
errores, enrutar datos y verificar que los mensajes lleguen a sus destinos previstos. Se establecería
un protocolo para definir cómo los IMP deberían comunicarse con las computadoras host.
Después de que se corrió la voz sobre la idea de Clark, la hostilidad inicial hacia la red disminuyó un
poco. Por un lado, una computadora separada para llevar a cabo las funciones de conmutación eliminó el
engorroso error (un error es una solución poco elegante a un problema técnico) que podría resultar de
agregar esas funciones a la computadora principal. La gente también lo vio como una forma de conseguir
otra computadora para jugar.
A finales de 1967, otra conferencia informática, ésta celebrada en Gatlinburg, Tennessee, ayudó a
avanzar en el plan de la red. Este simposio fue patrocinado por la Association for Computing Machinery, la
organización profesional más antigua y prestigiosa de la creciente industria informática. Aunque eran
pequeños en número, los asistentes representaban los niveles más altos del establishment informático.
Gatlinburg fue el lugar perfecto para que Roberts presentara su primer artículo sobre lo que llamó la "red
ARPA". En su presentación, Roberts se centró en las razones de la red y describió la subred de IMP,
pero dijo poco más sobre cómo funcionaría realmente la red. Un gran enigma aún por resolver era la
cuestión de cómo se transmitirían realmente los datos: a través de qué tipo de canal. Siempre
consciente de los costos, Roberts cerró su presentación con una breve discusión sobre lo que
llamó “necesidades de comunicación”. Estaba pensando en utilizar el mismo tipo de líneas telefónicas
que él y Marill habían utilizado para su pequeño experimento TX2: líneas fullduplex de cuatro hilos. La
conversación sobre el asunto terminó con una nota de frustración. Las líneas telefónicas ordinarias (a
diferencia de las dedicadas y arrendadas) eran lentas y mantener una línea abierta era un desperdicio.
Roberts todavía no había encontrado un medio muy eficaz para transportar los datos.
Mientras que la reunión de Ann Arbor meses antes había sido el equivalente intelectual de una pelea de
bar, Gatlinburg era una merienda inglesa. La gente estaba aceptando cortésmente la idea de una red. La
presentación de Roberts fue en general bien recibida, incluso algunos la recibieron con
entusiasmo.
Roger Scantlebury presentó otro artículo. Provenía del equipo de Donald Davies en el Laboratorio Nacional
de Física y hablaba del trabajo que se estaba realizando en Inglaterra. Su artículo presentó un estudio de
diseño detallado para una red de conmutación de paquetes. Era la primera vez que Roberts oía hablar de
ello. Posteriormente, Roberts y algunos otros se acercaron a Scantlebury y comenzaron a discutir el
trabajo de NPL. La discusión continuó en el bar del hotel y se prolongó hasta bien entrada la noche.
Scantlebury planteó la cuestión de la velocidad de la línea a Roberts. Dijo que él y Davies planeaban utilizar
líneas que funcionaran mucho más rápido que los 2.000 bits por segundo que proponía Roberts.
Sugirió que Roberts construyera la red ARPA.
con menos líneas transportando datos a velocidades más de veinte veces superiores para mejorar el
tiempo de respuesta.
Roberts también aprendió de Scantlebury, por primera vez, el trabajo que había realizado Paul Baran en
RAND unos años antes. Cuando Roberts regresó a Washington, encontró los informes RAND, que en
realidad habían estado acumulando polvo en la Oficina de Técnicas de Procesamiento de Información
durante meses, y los estudió. Roberts estaba diseñando esta red experimental no teniendo como
preocupación principal, o incluso secundaria, las comunicaciones de supervivencia. Los escenarios
de guerra nuclear y las cuestiones de mando y control no ocupaban un lugar destacado en la agenda de
Roberts. Pero los conocimientos de Baran sobre las comunicaciones de datos lo intrigaron de todos modos
y, a principios de 1968, se reunió con Baran. Después de eso, Baran se convirtió en una especie de consultor
informal del grupo que Roberts reunió para diseñar la red. El documento de Gatlinburg presentado
por Scantlebury en nombre del esfuerzo británico también fue claramente una influencia. Cuando visitó a
Roberts durante el diseño de la red ARPA, Davies dijo: "Vi que nuestro periódico se había utilizado tanto
que sus páginas se estaban cayendo a pedazos".
Roberts pensó que la red debería comenzar con cuatro sitios (UCLA, SRI, la Universidad de Utah y la
Universidad de California en Santa Bárbara) y eventualmente crecer hasta alrededor de diecinueve.
Se eligió UCLA como el primer sitio porque el Centro de medición de redes de Len Kleinrock estaba allí.
En cada uno de los otros sitios, ya se estaban llevando a cabo investigaciones patrocinadas por ARPA que
proporcionarían recursos valiosos a la red. Los investigadores de la UCSB estaban trabajando en gráficos
interactivos. Los investigadores de Utah también estaban haciendo mucho trabajo gráfico, además de
investigar la visión nocturna para los militares. Dave Evans, quien más tarde, junto con Ivan Sutherland,
fundó Evans and Sutherland, una empresa gráfica pionera, estaba en Utah armando un sistema que tomaría
imágenes y las manipularía con una computadora. Evans y su grupo también estaban interesados en saber
si la red podría usarse para algo más que intercambios textuales.
El Instituto de Investigación de Stanford (más tarde rompió sus vínculos con Stanford y se convirtió
simplemente en SRI) había sido elegido como uno de los primeros sitios porque Doug Engelbart, un
científico de extraordinaria visión, trabajaba allí. Varios años antes, cuando Bob Taylor estaba en la
NASA, había financiado la invención del primer ratón de computadora por parte de Engelbart (Engelbart
recibió una patente para el dispositivo como “indicador de posición XY para un sistema de visualización”),
y durante años después Taylor señaló con orgullo su apoyo al ratón de Engelbart.
Engelbart había asistido a la reunión de los investigadores principales de ARPA en Ann Arbor en 1967
cuando Taylor y Larry Roberts anunciaron que se esperaba que aproximadamente una docena de ellos
conectaran sus computadoras a través de una red experimental y que se esperaba que cada sitio hiciera
su trabajo. Recursos informáticos disponibles en la red. Mientras que otros habían reaccionado con
escepticismo al plan, Engelbart estaba encantado con él. En ese momento, dirigía un laboratorio de
investigación informática del SRI. Al igual que Licklider, Engelbart estaba interesado en utilizar las
computadoras para aumentar el intelecto humano. En virtud de un contrato de ARPA, estaba desarrollando
un sistema (llamado NLS, por oNLine System) que dependía de comunidades con conocimientos
de informática. Vio la red experimental ARPA como un vehículo excelente para extender NLS a una amplia
área de colaboración distribuida. "Me di cuenta de que había una comunidad informática ya preparada",
recordó Engelbart. "Era justo lo que estaba buscando".
Parte de la fortaleza de NLS fue su utilidad para crear bibliotecas digitales y almacenar y recuperar
documentos electrónicos. Engelbart también vio a NLS como una forma natural de respaldar un centro
de intercambio de información para la red ARPA. Después de todo, si la gente iba a compartir
recursos, era importante que todos supieran qué había disponible. En la reunión de Michigan,
Engelbart se ofreció como voluntario para montar el Centro de Información de Red, que llegó a ser
conocido como NIC (pronunciado “nick”). Engelbart también sabía que su grupo de investigación en
Menlo Park estaría igualmente entusiasmado con la red. Sus colegas eran programadores
talentosos que reconocían un proyecto interesante cuando lo veían.
La conversación con Scantlebury había aclarado varios puntos para Roberts. Los comentarios del
británico sobre la conmutación de paquetes en particular ayudaron a que Roberts se acercara más a
un diseño detallado. Al especificar los requisitos de la red, Roberts se guió por algunos principios
básicos. Primero, la subred IMP debía funcionar como un sistema de comunicaciones cuya tarea
esencial era transferir bits de manera confiable desde una ubicación de origen a un destino específico.
A continuación, el tiempo de tránsito medio a través de la subred debería ser inferior a medio segundo.
En tercer lugar, la subred debe poder funcionar de forma autónoma. Las computadoras de esa
época generalmente requerían varias horas por semana de tiempo de inactividad por mantenimiento.
Los IMP no podían darse el lujo de depender de una computadora anfitriona local o del personal
del sitio anfitrión; deberían poder continuar operando y enrutando el tráfico de la red independientemente
de que un host esté en ejecución o no. La subred también tuvo que continuar funcionando cuando
los IMP individuales dejaron de funcionar. Esta idea de que mantener la confiabilidad debería corresponder
a la subred, no a los hosts, era un principio clave. Roberts y otros creían que los IMP también deberían
ocuparse de tareas como la selección de rutas y el acuse de recibo.
A finales de julio de 1968, Roberts había terminado de redactar la solicitud de propuestas. Lo envió a 140
empresas interesadas en construir el procesador de mensajes de interfaz. El documento estaba
lleno de detalles sobre cómo debería ser la red y qué se esperaba que hicieran los IMP. Era una rica
pieza de prosa técnica, llena de una mezcla ecléctica de ideas. Kleinrock había influido en los primeros
pensamientos de Roberts sobre las posibilidades teóricas. Baran había contribuido a la base
intelectual en la que se basaba el concepto técnico, y el esquema de enrutamiento dinámico de Roberts
dio un guiño adicional al trabajo de Baran; Roberts había adoptado el término "paquete" de Davies e
incorporó sus velocidades de línea más altas y las de Scantlebury; La idea de la subred de Clark fue un
golpe de genialidad técnica. “El proceso de desarrollo tecnológico es como construir una catedral”,
comentó Baran años después.
“A lo largo de varios cientos de años, llega gente nueva y cada uno coloca un bloque encima de los
cimientos antiguos, y cada uno dice: 'Construí una catedral'. El mes siguiente se coloca otro bloque
encima del anterior. Entonces llega un historiador que pregunta: 'Bueno, ¿quién construyó la catedral?'
Pedro añadió algunas piedras aquí y Pablo añadió algunas más. Si no tiene cuidado, puede
convencerse de que hizo la parte más importante. Pero la realidad es que cada contribución tiene que
seguir a un trabajo anterior.
Todo está ligado a todo lo demás”.
Pero en 1968 el arquitecto principal de la red fue Larry Roberts: tomó las decisiones iniciales y
estableció los parámetros y especificaciones operativas. Aunque recibiría aportaciones de otros, Roberts
sería quien decidiría quién lo construiría.
Las primeras respuestas a la solicitud de propuestas provinieron de IBM y Control Data Corporation
(CDC). IBM era entonces el mayor fabricante de ordenadores del mundo y dominaba el mercado de
grandes sistemas informáticos. CDC, aunque eclipsada por IBM, era otra empresa que había invertido
mucho en el desarrollo de sistemas de gran tamaño. Ambos declinaron ofertar y sus razones eran idénticas: la
red nunca podría construirse, dijeron rotundamente, porque no existían computadoras lo suficientemente
pequeñas como para hacerla rentable. Para el IMP, IBM había pensado en proponer un ordenador 360 Modelo
50, un gran mainframe. Pero a un precio muchas veces mayor que el de una minicomputadora, el Modelo 50
era demasiado caro para considerar comprarlo en grandes cantidades.
Roberts, por otro lado, pensaba en pequeño. La primera computadora en la que pensó fue la PDP8, una
minicomputadora fabricada por Digital Equipment Corp. Digital había lanzado la PDP8 en 1965. No sólo fue
el primer gran éxito de la compañía, sino que la PDP9 también estableció las minicomputadoras como el nueva
vanguardia de la industria informática. Roberts conocía a Ken Olsen de Lincoln y pensó que Digital podría
incluso ofrecer un descuento por cantidad en la máquina.
Cuando empezaron a llegar ofertas, la mayoría había elegido una computadora Honeywell. Era una
minicomputadora llamada DDP516; Honeywell acababa de presentarlo. Parte del prestigio de la nueva
máquina era que podía construirse según especificaciones de servicio pesado. En su versión
“resistente”, costaba alrededor de 80.000 dólares. Poco después de la presentación de la máquina, en una
conferencia informática en Las Vegas, una grúa levantó la versión militar reforzada de la sala de exposición.
Mientras colgaba de las cuerdas atadas a la grúa, un empleado de Honeywell le aplicó un mazo. El objetivo
del ejercicio era demostrar que la máquina era lo suficientemente resistente para operar en el campo de
batalla. Para los postores, el atractivo más probable del 516 fue su impresionante relación costerendimiento
y el diseño de su sistema de entrada/salida.
Se presentaron más de una docena de ofertas, lo que dio como resultado una pila de papel de dos metros.
La empresa de Marill, CCA, presentó una oferta conjunta con Digital. Raytheon hizo una oferta, al igual que
BunkerRamo. Roberts quedó gratamente sorprendido de que varios de los encuestados creyeran que podían
construir una red que funcionara más rápido que el objetivo indicado en las especificaciones.
Raytheon era uno de los favoritos. Raytheon, un importante contratista de defensa en el área de Boston,
especializado en componentes de sistemas electrónicos, ya había propuesto construir una red informática de
alta velocidad y corta distancia. A mediados de diciembre, Roberts inició negociaciones finales con Raytheon
para el contrato IMP. Los funcionarios de Raytheon respondieron las preguntas técnicas restantes de ARPA
y aceptaron el precio.
Por eso sorprendió a todos cuando, apenas unos días antes de Navidad, ARPA anunció que el contrato para
construir los procesadores de mensajes de interfaz que residirían en el núcleo de su red experimental se
adjudicaría a Bolt Beranek y Newman, una pequeña empresa consultora de Cambridge. Massachusetts.
3
La tercera universidad
Cuando Richard Bolt y Leo Beranek fundaron su empresa de consultoría en 1948, la informática
avanzada no estaba en sus mentes. Beranek era ingeniero eléctrico, Bolt arquitecto y físico. Ambos
eran acústicos y miembros de la facultad del MIT durante la década de 1940.
Bolt había trabajado para la Armada en la Segunda Guerra Mundial en métodos para utilizar el
sonido para detectar submarinos. Después de la guerra, como jefe del laboratorio de
acústica del MIT, Bolt trabajó como consultor, al igual que Beranek. El MIT comenzó a recibir
solicitudes de ayuda en planificación acústica para nuevos edificios en todo el país y se las pasó a Bolt y Beranek.
Independientemente el uno del otro, los dos ya habían trabajado bastante en lo que se conoce
como acústica aérea (el sonido transmitido en salas de conciertos y cines), así como en el control y
reducción del ruido en edificios.
Cuando las Naciones Unidas le pidieron a Bolt que diseñara la acústica de su nuevo complejo
de edificios en un antiguo distrito de mataderos en el East River de Manhattan, Bolt llamó a
Beranek a su oficina y le mostró la pila de papeles que detallaban el trabajo de la ONU. Era demasiado
para que lo asumiera una sola persona. En ese momento, Beranek estaba ocupado en un
proyecto para mejorar la acústica de una cadena de cines de Brooklyn. Pero Bolt convenció a Beranek
para que se uniera a él para iniciar una empresa de consultoría para asumir el proyecto de la ONU.
Un año después acogieron a Robert Newman, un arquitecto con formación en física que había sido
alumno de Bolt, y nació Bolt Beranek y Newman.
En sus inicios, BBN era verdaderamente una empresa de consultoría. Es decir, Bolt y Beranek
contrataron gente, les proporcionaron espacio para oficinas y esperaron que encontraran el trabajo. Y
encontrar el trabajo que hicieron. El proyecto de la ONU tuvo un éxito tan notorio que la empresa no
necesitó publicidad durante los primeros diez años de su existencia. El negocio creció a medida
que BBN asesoraba sobre el diseño de sistemas acústicos para edificios de oficinas, complejos de
apartamentos y centros de artes escénicas. Cuando se construyó un gran túnel de viento para
probar motores a reacción cerca de Cleveland, el ruido molestó a la gente en un radio de diez millas
y los residentes locales amenazaron con cerrar las instalaciones. Los ingenieros de BBN descubrieron
una manera de amortiguar el sonido. La empresa estaba adquiriendo experiencia en el análisis de
cintas de audio: fue llamada a trabajar después del asesinato del presidente John F. Kennedy en
1963 y volvería a ser llamada después del tiroteo en la Universidad Estatal de Kent en 1970. Su
análisis de cinta más famoso se produciría durante el Escándalo Watergate en 1974, cuando BBN se
involucraría en el análisis del infame intervalo de 18,5 minutos en las cintas de Nixon. Un comité
encabezado por Dick Bolt concluiría que el borrado fue deliberado.
En 1957, Beranek había reclutado a Licklider para BBN. Había trabajado con Lick en Harvard
durante la guerra, y cuando fue al MIT, lo convenció para que fuera allí también. Cuando Beranek
contrató a Lick en BBN, lo que Beranek pensó que era interesante no era tanto la experiencia de Lick
en psicoacústica sino su interés en la interacción hombremáquina. Beranek intuyó que los trabajos
de consultoría aumentarían en el negocio de ayudar a las empresas a construir máquinas que
fueran amplificadores más eficientes del trabajo humano, lo que significaba lograr algún tipo de
compatibilidad entre humanos y máquinas. “No sabía cuán grande era el negocio”, recordó más tarde
Beranek. "Pero pensé que era un buen complemento a lo que estábamos haciendo".
Lick, por supuesto, lo había pensado más detenidamente. Creía que el futuro de la investigación
científica iba a estar vinculado a las computadoras de alta velocidad y pensaba que la informática era un
buen campo en el que BBN podía ingresar. Llevaba menos de un año en BBN cuando le dijo a
Beranek que le gustaría comprar una computadora. A modo de persuasión, Lick destacó que la
computadora que tenía en mente era una máquina muy moderna: sus programas y datos estaban
grabados en cinta de papel en lugar de en las pilas convencionales de tarjetas IBM.
“¿Cuánto costará?” —le preguntó Beranek.
“Alrededor de 25.000 dólares”.
“Eso es mucho dinero”, respondió Beranek. "¿Que vas a hacer con eso?"
"No sé."
Licklider estaba convencido de que la empresa podría conseguir contratos del gobierno para
realizar investigaciones básicas utilizando computadoras. Los 25.000 dólares, le aseguró a Beranek,
no se desperdiciarían.
Ninguno de los tres directores de la empresa sabía mucho sobre computadoras. Beranek sabía que Lick,
por el contrario, era casi evangelista en su creencia de que las computadoras cambiarían no sólo la
forma en que la gente pensaba acerca de los problemas, sino también la forma en que se resolvían.
La fe de Beranek en Licklider triunfó. “Decidí que valía la pena correr el riesgo de gastar 25.000
dólares en una máquina desconocida para un propósito desconocido”, dijo Beranek. La computadora que
compró para Lick fue una LGP30, fabricada en 1958 por RoyalMcBee, una subsidiaria de Royal
Typewriter Company. Tenía memoria de batería y era lento incluso para los estándares de su época. Sin
embargo, Lick se puso manos a la obra y lo utilizó para largos cálculos estadísticos y experimentos
psicoacústicos.
Poco después de que llegara la computadora, Ken Olsen pasó a ver la máquina RoyalMcBee y a
contarle a BBN sobre la computadora que estaba construyendo en su nueva empresa, Digital Equipment.
Olsen quería prestarle a Beranek un prototipo de la máquina, a la que llamó PDP1, para que los
ingenieros de BBN pudieran echarle un vistazo. Beranek estuvo de acuerdo. Pero la computadora medía
cuatro pies por ocho pies, y había pocas puertas en BBN por las cuales pasarla. Así se instaló en el
vestíbulo. Aproximadamente un mes después, después de que todos tuvieron la oportunidad de jugar con
él, BBN se lo devolvió a Olsen con recomendaciones para realizar ajustes. Cuando el PDP1 salió al
mercado por poco menos de 150.000 dólares, BBN compró el primero.
La presencia del PDP1 y el trabajo que Licklider estaba haciendo con él atrajo a varios científicos
informáticos destacados a BBN. La empresa también se había hecho conocida como un lugar cuya
filosofía de contratación era reclutar desertores del MIT. La idea era que si podían ingresar al MIT serían
inteligentes y, si lo abandonaban, se podría conseguirlos más baratos. Beranek le dio a Lick mucha
libertad para contratar a quien quisiera, y Licklider hizo precisamente eso, olvidándose ocasionalmente
de decírselo a Beranek. “Un día estaba deambulando por el edificio para ver qué estaba pasando en la
parte de la computadora y vi a dos tipos extraños sentados en una de las salas grandes”, dijo Beranek.
(A Lick le habría encantado ir de traje a un picnic, pero sus empleados eran decididamente menos
formales). Beranek no tenía idea de quiénes eran los dos hombres. “Me acerqué al primer individuo y le
dije: '¿Quién eres?' y él dijo: '¿Quién
¿Y tú?'”. Resultó que los dos jóvenes eran amigos de Licklider del MIT.
Marvin Minsky y John McCarthy, dos de las figuras más destacadas en el emergente campo de la inteligencia
artificial.
El PDP1 tenía una potencia informática aproximadamente equivalente a la de los organizadores de bolsillo
actuales y un poco menos de memoria. La gente de BBN mantenía la computadora encendida día y
noche realizando programación interactiva. Incluso construyeron un sistema de tiempo compartido a su
alrededor, dividiendo la pantalla para cuatro usuarios simultáneos. La demostración de tiempo compartido
fue un éxito y BBN decidió iniciar un servicio de tiempo compartido en el área de Boston colocando
terminales por toda la ciudad. Sin embargo, pronto General Electric montó un esfuerzo similar y
rápidamente robó la mayor parte del negocio de tiempo compartido de BBN.
La presencia de un ordenador accesible inspiró un cambio en la empresa. Todos empezaron a pensar en

cosas que se podrían hacer con él. Un científico del BBN, Jordan Baruch, decidió que los hospitales podrían
utilizar computadoras para mantener información más precisa sobre los pacientes, por lo que se propuso
informatizar el manejo de registros en el Hospital General de Massachusetts. Lick y otros comenzaron a
explorar formas en que las computadoras podrían transformar las bibliotecas. Pero a principios de la
década de 1960 las computadoras todavía tenían poca potencia para hacer mucho.
En ese momento, BBN había comenzado a concentrarse seriamente en la tecnología informática. El rico
ambiente académico de BBN le valió a la consultora la reputación de ser “la tercera universidad” de Cambridge.
“Tenía la política de que cada persona que contratáramos tenía que ser mejor que las anteriores”, dijo
Beranek. Junto al MIT y Harvard, BBN se convirtió en uno de los lugares más atractivos para trabajar en el área
de Boston. Algunas personas incluso lo consideraban mejor que las universidades porque no había
obligación de enseñar ni preocupación por obtener la titularidad. Era un ambiente enrarecido: el coñac del
negocio de la investigación.
La división de arquitecturaacústica de la firma atravesó una crisis a principios de la década de 1960, cuando
Beranek fue contratado para diseñar la acústica del nuevo Philharmonic Hall (más tarde rebautizado como
Avery Fisher Hall) en el Lincoln Center de Nueva York. Tanto Beranek como el arquitecto jefe fueron criticados
por pasar por alto ciertos principios acústicos importantes en el diseño de salas de conciertos. Después
de muchos intentos de realizar pequeños ajustes, quedó claro que la situación era desesperada. El problema
tuvo que resolverse por la fuerza bruta: se arrancaron las paredes y los balcones, junto con el techo (diez mil
toneladas de material de construcción en total) y se llevaron a los vertederos. La reparación requirió varios años
y millones de dólares, bajo la supervisión de un nuevo consultor. En su exhaustiva cobertura de los
problemas, el New York Times centró su atención en Leo Beranek.
Si BBN no se hubiera diversificado ya en la investigación informática, la debacle del Lincoln Center podría
haber significado su fin. Sin embargo, a mediados de la década de 1960, las oficinas de la empresa se
habían ampliado hasta convertirse en una hilera de edificios bajos y bastante anodinos, en su mayoría
antiguos almacenes que se alzaban a lo largo de una tranquila calle lateral cerca de Fresh Pond, en el extremo
occidental de Cambridge. Las oficinas tenían una uniformidad arquitectónica casual que se describe mejor
como modernismo de bajo alquiler: Mondrian sin colores. Se trataba de edificios sencillos, sobrios, con forma
de cajas, cuyos techos planos, pocas ventanas y paredes delgadas irradiaban simplicidad y economía
en el diseño. Cuatro de los edificios se habían construido para otros fines, principalmente como espacio de
almacenamiento, antes de que BBN los comprara y los convirtiera en oficinas, tiendas y laboratorios. El edificio número 2 era
Diseñado por el propio Bolt y tenía un par de características inusuales: sus cimientos “flotaban” en el
barro de Cambridge, aislando efectivamente toda la estructura de las vibraciones externas; y estaba
diseñado para el tipo de personas que BBN estaba contratando (académicos) de quienes Bolt esperaba
que llenaran sus oficinas con libros. Por lo tanto, diseñó el nuevo edificio para soportar una
cantidad inusual de peso. Entre todos los edificios del BBN había pasillos y pasarelas cerradas, lo
que permitía recorrer una especie de camino serpenteante a lo largo de toda la hilera sin salir al exterior
durante el invierno. Durante un tiempo, BBN dependió del vapor prestado proveniente de una
lavandería adyacente para calentar algunas de las habitaciones.
Entre los investigadores informáticos se encontraban Wally Feurzeig y Seymour Papert, que
trabajaban en aplicaciones educativas. Papert fue consultor de BBN durante unos cuatro años a finales
de los años sesenta. Mientras estuvo allí, concibió e hizo el primer diseño aproximado de un
lenguaje de programación que sería accesible para niños en edad escolar. La idea fue adoptada
como tema de investigación por el grupo de educación de BBN, dirigido por Feurzeig, y el lenguaje
pasó a llamarse LOGO.
Mientras que los acústicos solían venir a trabajar con chaqueta y corbata, en el lado de los
ordenadores el ambiente era decididamente más relajado. "Cuando entramos en el negocio de la
informática, teníamos gente muy extraña trabajando para nosotros", dijo Beranek. Apreciaba la
brillantez de las personas que Lick contrataba, pero rara vez se sentía cómodo con ellas. Recordó haber
sido invitado a una fiesta de Nochevieja en la casa de un ingeniero informático alrededor de 1965. "Era
como ir a la casa de la familia Addams", dijo Beranek. “Estaban todos descalzos. Las mujeres
vestían ropa ajustada. Llegué con corbata y me la tuve que quitar”.
Frank Heart fue una notable excepción. Conservador en su vestimenta y propenso a la cautela en
general, Heart era en ese momento ingeniero de sistemas informáticos en el Laboratorio Lincoln del
MIT. En 1966, BBN se embarcó en una campaña para contratarlo para el proyecto de informática de
su hospital. Heart era un ingeniero con reputación de hacer que las cosas sucedieran. Dile que
querías que construyeran algo y, por Dios, lo tendrías. Pero Heart también era testarudo y no era fácil
alejarse de Lincoln.
Heart, que se describe a sí mismo como un “niño judío sobreprotegido de Yonkers”, era un aficionado
a los libros y, en la escuela secundaria, un poco nerd. Frank deseaba desesperadamente asistir
al MIT, lo que planteaba un problema para sus padres, que eran de recursos modestos. (Durante la
Depresión, el padre de Heart logró mantener su trabajo como ingeniero en Otis Elevator.) La idea de
enviar a su único hijo a una escuela tan lejana fue particularmente difícil para la madre de Frank,
quien se encargó de la mayor parte de la sobreprotección. El MIT lo admitió en 1947, pero con
una beca tan pequeña que garantizaba continuas luchas financieras para sus padres.
Siguiendo el ejemplo de su padre, que construía sistemas de control de ascensores, Frank decidió
convertirse en ingeniero eléctrico antes de ingresar al MIT. Para aliviar la presión financiera de su familia,
se matriculó en un programa de maestría de cinco años, en el que el trabajo y la escuela se
combinaban en semestres alternos. Trabajó un verano en una fábrica de General Electric
probando grandes transformadores de potencia. “Eso era algo que querías hacer sólo una vez”,
recordó Heart. En su segundo año, optó por especializarse en energía.
ingeniería: el diseño de sistemas eléctricos a gran escala, como plantas de energía, transformadores
de edificios, generadores y motores.
Luego descubrió las computadoras. En 1951, el último año de Heart, el MIT ofreció su primer curso
sobre programación informática, impartido por un profesor visitante llamado Gordon Welchman.
Corazón registrado. "Para mí fue una revelación increíble que pudiera existir algo como una
computadora", dijo Heart. Abandonó el programa de estudio y trabajo, una decisión que
sorprendió a mucha gente porque era un programa muy difícil de ingresar. “Recibí todo tipo de
cartas desagradables del MIT y GE”. Pero se había contagiado del virus informático y nunca
miró hacia atrás.
Gracias a la introducción de Welchman, Heart se interesó tanto en las computadoras que obtuvo
su licenciatura un trimestre antes y terminó su maestría mientras trabajaba como asistente
de investigación en el Proyecto Whirlwind. Whirlwind controlaba un sistema de defensa por radar
para rastrear aviones. Un sistema de radar (RAdioD etectionA ndR anging) mide los pulsos
electromagnéticos reflejados por un objeto para proporcionar información sobre su dirección
y distancia. Los dispositivos de interferencia pueden destruir datos de un solo radar, pero una
serie de radares pueden compensarlo si funcionan en conjunto con una computadora.
Whirlwind le dio a Heart su primera experiencia con la programación en un entorno de
tiempo real. Cuando Whirlwind fue transferido al Laboratorio Lincoln, Heart fue transferido con
él. “Fue el tipo de cambio de trabajo más indoloro que uno pudiera imaginar”, dijo Heart.
Muchos programas en la década de 1950 fueron escritos en “lenguaje de máquina”, las instrucciones
reales en el “lenguaje natural” de la computadora. Las órdenes debían especificarse con todo
detalle; había una correspondencia uno a uno entre cada línea del programa y cada instrucción a la
máquina. Trabajar en lenguaje de máquina podía resultar tedioso y los errores eran difíciles de
encontrar y corregir. Pero dio a los programadores un fuerte sentido de identificación
con la máquina. La programación informática era todavía tan nueva que pocas personas entendían
sus complejidades. Muchos de los que trabajaban en las ciencias más tradicionales ignoraron (o
descartaron) a quienes exploraban las computadoras como una ciencia.
El Laboratorio Lincoln estaba demostrando ser una incubadora perfecta para el tipo de genio
que ARPA necesitaría para impulsar la informática a la era interactiva e interconectada. Ya se había
convertido en un caldo de cultivo para algunos de los primeros trabajos más importantes en
informática y redes. Muchos de sus alumnos (entre ellos, Licklider, Roberts, Heart y otros aún por
venir) desempeñarían papeles cruciales en el diseño y desarrollo de la red ARPA. En los primeros
días, los programadores informáticos de Lincoln estaban mal considerados. Sólo se permitía
formar parte del personal de investigación a físicos y matemáticos de pleno derecho y, como
resultado, muchos programadores abandonaron Lincoln. Pero Heart rompió el prejuicio.
Comenzó como estudiante de posgrado en programación, se convirtió en miembro del personal y
en poco tiempo dirigía un grupo.
Heart también ignoró las reglas. Tenía poca tolerancia hacia las delineaciones profesionales y no
se tomaba los títulos demasiado en serio. Cuando un joven programador llamado Dave Walden
llegó a trabajar a Lincoln, lo contrataron con el título de asistente técnico. El hecho de que no se
trataba de un puesto de nivel personal estaba claramente indicado en su placa de seguridad.
Los títulos eran importantes en Lincoln y, entre otras cosas, la insignia lo mantenía fuera del personal.
seminarios. Haciendo caso omiso de todo eso y desobedeciendo el protocolo que asignaba a los no empleados
el espacio de trabajo menos deseable, Heart instaló a Walden en una oficina con uno de sus mentores, un joven
graduado del MIT llamado Will Crowther. Crowther era un físico convertido en informático.
A finales de la década de 1950 y principios de la de 1960, Heart, Crowther y otras personas cercanas a ellos
trabajaron en un proyecto innovador tras otro. Con el tiempo, Heart y su equipo en Lincoln se convirtieron en
expertos en conectar una variedad de dispositivos de medición a computadoras a través de líneas telefónicas
para recopilar información. Esto, a su vez, los convirtió en expertos en la construcción de sistemas informáticos
en tiempo real.
Cuando un grupo de colegas de Heart se fue para fundar MITRE Corporation en 1958, Heart permaneció
firmemente amarrado a Lincoln, en parte porque siempre le habían disgustado los cambios y en parte porque
amaba lo que estaba haciendo. No podía imaginarse jamás tener un trabajo más interesante o un grupo con
más talento con el que trabajar.
En el verano de 1965, Heart conoció a Danny Bobrow, que había estado trabajando en inteligencia artificial
en BBN. Bobrow le sugirió a Heart que dejara Lincoln para trabajar en BBN, supervisando un proyecto para
introducir tecnología informática en los hospitales. Cuando Heart se negó, Dick Bolt intervino.
Una de las razones por las que los directores de BBN estaban ansiosos por cortejar a Heart era que tenía
una experiencia fructífera en la creación de sistemas que funcionaban eficientemente en el campo. La
empresa necesitaba a alguien así. A pesar de toda su innovación, BBN no había tenido mucho éxito en
convertir sus ideas en sistemas funcionales y utilizables. "La cultura en BBN en ese momento era hacer cosas
interesantes y pasar a la siguiente cosa interesante", dijo un ex empleado. Había más incentivos para proponer
ideas interesantes y explorarlas que intentar sacar provecho de ellas una vez desarrolladas.
Bolt invitó a Heart a su casa. Tuvieron más reuniones en BBN. Se conocieron en el Howard Johnson's local.
Heart seguía reacio, pero había aspectos del trabajo de BBN que le atraían. Al igual que Licklider, Heart siempre
había sostenido lo que él describió como una visión del “bienhechor”: Heart creía que las
computadoras y la tecnología podían ayudar a la sociedad.
Unido como estaba al ejército, el Laboratorio Lincoln nunca se había alejado mucho de las necesidades de la
Fuerza Aérea. De hecho, el limitado enfoque del laboratorio había precipitado la partida de personas como Ken
Olsen y Wes Clark, quienes se fueron para construir computadoras. Heart también estaba interesado en la
aplicación de las computadoras a las ciencias biológicas y Bolt le hizo saber que tendría la oportunidad de
desarrollar ese interés en BBN. Además, un amigo de Heart de Yonkers, Jerry Elkind, estaba en BBN, y Heart
respetaba bastante a Elkind. “También se me ocurrió”, admitió Heart, “que existía la posibilidad de ganar
algo de dinero en una corporación privada”.
Al final, Bolt lo convenció para aceptar el trabajo, pero cuando Heart llegó a BBN, la investigación informática
de la empresa la llevaban a cabo dos divisiones separadas: ciencias de la información y sistemas
informáticos. Como regla general, aquellos con doctorado trabajaban en la división de ciencias de la información o
investigación, mientras que aquellos sin doctorado trabajaban en la división de sistemas informáticos. Un
miembro de la división de ciencias de la información describió la división de sistemas informáticos como
si estuviera formada por un grupo de tipos con soldadura
hierros. En otras palabras, simplemente construyeron cosas, mientras que los de la división de
investigación se consideraban más preocupados por inventar el futuro. No hubo mucha polinización
cruzada entre los dos grupos. Trabajaban en edificios separados, separados por una estrecha pasarela
acristalada. No era exactamente animosidad lo que los separaba, ni tampoco rivalidad. Cada uno era
consciente de las limitaciones del otro, lo que resultaba en una notoria falta de interés en lo que sucedía
en el otro campo. Frank Heart era un tipo de sistemas de principio a fin.
Ofertas
Cuando la solicitud de propuestas de ARPA para construir el IMP llegó a BBN en agosto de 1968, la
empresa tuvo treinta días para responder. Jerry Elkind, que ahora era el jefe de Heart, estaba a
cargo de ambas divisiones informáticas. Pensó que BBN debería presentar una oferta y pensó que
Heart era la mejor persona de la empresa para gestionarla. Desde que desapareció el proyecto
informático del hospital poco después de su llegada, Heart había estado buscando un proyecto a largo
plazo en el que sumergirse. Además, Heart probablemente tenía la mayor experiencia en la construcción
del tipo de sistema informático que ARPA buscaba. Sin embargo, cuando Elkind sugirió que se
hiciera cargo, Heart se mostró normalmente cauteloso.
Heart podría ser difícil de interpretar al principio. Alex McKenzie, que trabajó intermitentemente para
Heart durante veintisiete años, recordó la primera vez que se encontró con su nuevo jefe, desde el otro
extremo de un pasillo. Heart hablaba en voz alta y aguda con otra persona y parecía agitado. "Estaba
realmente gritando y pensé que debía ser un problema".
recordó McKenzie. “Luego descubrí que era simplemente entusiasmo”. Unos años más tarde, mientras
viajaba en avión con Heart, McKenzie finalmente le contó su impresión inicial.
Heart arqueó las cejas. "¡¿GRITOS?!" Heart gritó, su voz alcanzando su característico falsete,
lo suficientemente fuerte como para atraer la atención de todos los que los rodeaban. "¡Yo no grito!" No,
claro está, cuando está enojado. "Cuando está enojado, se queda muy callado", dijo McKenzie.
En ocasiones, los encuentros con Heart implicaban muchos gritos. “Y luego, al día siguiente, resulta
que escuchó lo que usted dijo a pesar de todos los gritos y gritos”, recordó otro empleado de mucho
tiempo. “Si estabas dispuesto a aguantar los gritos y los gritos, él hacía que las cosas salieran bien, a
diferencia de la mayoría de las personas que gritan y gritan”. Heart tenía una energía prodigiosa, lo
que le hacía difícil permanecer sentado durante más de unos minutos seguidos.
Estaba más relajado cuando estaba en casa, trabajando en el taller de carpintería del sótano, donde
silbaba impecablemente largas y complejas piezas musicales, y rara vez era consciente de que lo
estaba haciendo. Cuando las cosas estaban tensas o inciertas, se mordía las uñas o tamborileaba
con los dedos sobre las mesas.
Heart era intensamente leal a las personas que trabajaban para él y ellos a su vez le eran leales.
También era cariñoso, no sólo con sus tres hijos (asumió felizmente muchas tareas de cuidado de
niños que no se esperaban de los maridos en aquellos días), sino también con sus empleados. Al
mismo tiempo, se tomaba muchas cosas como algo personal, sobre todo cuando la gente dejaba su
grupo para ir a trabajar a otro lugar, aunque fuera al otro lado del pasillo, a otra división.
Una de las mayores fortalezas de Heart fue asegurarse de que los trabajos para los que se inscribió
realmente se hicieran, y al aceptar el trabajo de ARPA le preocupaba el riesgo de comprometer a la
empresa con algo que tal vez no podría lograr. El proyecto estuvo lleno de incertidumbres y tecnología
inexplorada. A Heart le resultó difícil evaluar exactamente lo que estaba involucrado. No había tiempo
para hacer el tipo de planificación detallada que le gustaría hacer en un proyecto de software de
sistemas, como estimar la cantidad de líneas de código que se necesitarían.
La evaluación de riesgos es esencial en cualquier empresa de ingeniería. Dado que ningún

proyecto tecnológico importante puede estar completamente libre de riesgos, se factorizan y pesan las
probabilidades de éxito y fracaso de diseños particulares. El potencial de problemas se divide en
tres categorías: lo previsto, lo imprevisto pero previsible y lo imprevisible. En este último caso los ingenieros
se ven obligados a tomar decisiones con los dedos cruzados. La situación que afrontaba Heart
entraba en gran medida en esta última categoría, ya que gran parte del sistema no tenía
precedentes en los que basar las estimaciones de riesgo.
Las incertidumbres sobre el software eran bastante graves, pero existían muchas otras incógnitas.
Por ejemplo, ¿cuánto tráfico podría manejar una red de este tipo sin encontrarse con atascos?
¿Cuál era la probabilidad de que la falla de un nodo se propagara a través de la red? En noviembre de
1965, por ejemplo, un relé sobrecargado provocó un efecto dominó que provocó la caída de la red
eléctrica que daba servicio a todo el noreste de Estados Unidos.
Sobre todo, ¿cuál era la probabilidad de que la red funcionara? Registrarse en un proyecto como la red
ARPA requirió cierta fe, y eso perturbó a Heart.
Elkind estaba motivado por su sensación de que ARPA estaba impulsando el estado del arte de
la informática hacia una nueva era y, desde un punto de vista empresarial, tenía mucho sentido lanzar
BBN hacia ese futuro. Elkind reconoció que las preocupaciones de Heart eran racionales.
"Pero me di cuenta de que este era un contrato que teníamos que cumplir y que podíamos cumplir tan bien como cualquiera".
Dijo Elkind. "Sabíamos cómo trabajar con ARPA y teníamos conocimientos de informática tan
buenos como cualquiera".
Elkind sugirió a Heart que un pequeño grupo de BBN se reuniera para decidir qué hacer con la solicitud
de propuestas de ARPA. Acordaron reunirse informalmente y eligieron como lugar la casa de Danny
Bobrow en Belmont. La primera reunión se prolongó hasta bien entrada la noche.
Cuando terminó, Heart se había convertido y la participación de BBN estaba prácticamente garantizada.
Esa fue la parte fácil. Luego tuvieron sólo un mes para redactar una propuesta detallada. Una de las
primeras personas en involucrarse en la propuesta fue Bob Kahn, profesor de ingeniería eléctrica con
licencia del MIT y que trabaja en la división de ciencias de la información de BBN. En el MIT, Kahn había
sido un matemático aplicado que trabajaba en teoría de la información y las comunicaciones. La
mayoría de sus colegas poseían una combinación de habilidades de ingeniería teórica y aplicada. Un
día, Kahn estaba hablando con un colega senior del MIT sobre los diferentes problemas técnicos que le
interesaban y le preguntó: "¿Cómo puedes saber cuándo un problema es más interesante que otro?".
"Es sólo experiencia"
Respondió el colega de Kahn. “¿Cómo se consigue eso?” Preguntó Kahn. "Encuentra a alguien
que tiene mucha experiencia y ve a trabajar con él”. Un lugar obvio para que Kahn adquiriera esa
experiencia fue BBN. Así que se fue.
Por coincidencia, en 1967, en el momento en que Larry Roberts estaba en Washington formulando el
proyecto de red y sus requisitos, Kahn estaba en BBN teniendo sus propias ideas sobre la creación
de redes. Lo que es aún más coincidente es que, a instancias de Jerry Elkind, había estado enviando
memorandos técnicos no solicitados a Bob Taylor y Roberts. Cuando Roberts le dijo a Kahn que ARPA
planeaba financiar una red nacional, fue una revelación agradable para Kahn.
Entonces Elkind le dijo que un grupo de la división de sistemas informáticos de BBN estaba interesado
en elaborar una propuesta para la red ARPA y sugirió que Kahn se involucrara en el proceso.
Poco después, Frank Heart se dirigió a la oficina de Kahn. “Jerry me ha dicho que has estado
pensando en el área de networking. ¿Podemos charlar sobre eso?
“Sí, claro”, respondió Kahn. "¿Quién eres?"
En 1968, BBN tenía más de seiscientos empleados. El grupo de Frank Heart ocupaba una hilera de
oficinas a lo largo de un tramo de corredor revestido de linóleo en el Edificio Número 3. En un extremo
del pasillo había una sala de conferencias con muchas pizarras y asientos para grandes
reuniones. Las oficinas en sí eran pequeñas y sencillas, con escritorios hechos a partir de puertas a
las que el taller de construcción de BBN les había colocado patas. Las sillas de madera con respaldo
rígido y las sillas de director con respaldo de lona eran los estilos preferidos. Iluminación fluorescente,
algunos efectos personales, muchas estanterías y poco más completaban el cuadro.
A Heart le gustaba trabajar con grupos pequeños y muy unidos compuestos por personas muy brillantes.
Creía que la productividad y el talento individuales no variaban en factores de dos o tres, sino en factores
de diez o cien. Debido a que Heart tenía una habilidad especial para detectar ingenieros que podían
hacer que las cosas sucedieran, los grupos que había supervisado en Lincoln tendían a ser
inusualmente productivos.
Una de las primeras personas a las que Heart llamó para ayudar con la propuesta de IMP fue
Dave Walden, quien había seguido a Heart desde Lincoln hasta BBN. Aunque joven, con sólo cuatro o
cinco años de experiencia en programación, Walden tenía una experiencia muy cultivada en sistemas
en tiempo real, ideal para el trabajo de la red ARPA. Next Heart seleccionó a Bernie Cosell, un joven
programador que había estado trabajando en la división de sistemas informáticos de BBN. Cosell era un
depurador por excelencia, alguien que podía husmear en un programa de ordenador que nunca
había visto antes y solucionar en dos días un problema que llevaba semanas sin resolver. Heart también
reclutó a Hawley Rising, un ingeniero eléctrico de voz suave que era un viejo amigo de la época de
estudiante de Heart en el MIT.
El as del hardware de Heart era Severo Ornstein, un ex alumno de Lincoln de treinta y ocho años que
había trabajado para Heart de forma intermitente durante años. Ornstein fue un hombre intenso de
muchos y diversos intereses. Hijo de un pianista virtuoso y un compositor destacado, Ornstein había
asistido a Harvard y había coqueteado brevemente con una especialidad en música antes de que sus
padres lo disuadieran de hacerlo. Finalmente se decidió por la geología. Después de dejar Harvard,
Ornstein se interesó por las computadoras y se fue a trabajar a Lincoln. Cuando su colega Wes Clark
Cuando se fue a la Universidad de Washington en St. Louis para construir una computadora de
su propio diseño, Ornstein fue con él. Después de tres años en St. Louis, Ornstein deseaba
regresar a Cambridge, por lo que llamó a Heart, quien le ofreció un puesto en BBN.
Cuando llegó la solicitud de propuestas de ARPA, Heart le entregó una copia a Ornstein y le dijo: "¿Por
qué no te llevas esto a casa y le echas un vistazo, a ver qué te parece?". Ornstein regresó a la oficina
de Heart al día siguiente y dijo: “Bueno, claro, supongo que podríamos construirlo si quisieras. Pero
no veo para qué querríamos algo así”. No obstante, Ornstein pensó que el proyecto de construcción de
IMP parecía divertido, lo cual siempre fue una consideración primordial para él.
Heart tenía predilección por juzgar a las personas no por su apariencia, sus modales o sus
opiniones políticas, sino casi exclusivamente por lo inteligentes que creía que eran. O, como le
gustaba decir, por cuántas neuronas por centímetro cúbico contenían sus cerebros. Si decidía
que el número era inusualmente alto, era probable que Heart tolerara mucha más idiosincrasia en
uno que en otro cuya materia gris, en su opinión, estaba menos densamente empaquetada. Al
hablar, Heart solía utilizar jerga informática en circunstancias no técnicas. “No es una operación”, podría
decirle a su esposa Jane si decidieran dejar un domingo por la tarde libre. (Noop, o ninguna
operación, se refiere a una línea de código que no logra nada). O podría decirle: "Es binario" a
uno de sus hijos pequeños, lo que significa que es una situación en blanco y negro.
La habilidad de Heart para formar equipos de ingeniería eficaces lo había convertido en un gestor
de proyectos valioso y muy respetado. Buscó personas que estuvieran comprometidas con una misión
común en lugar de una agenda personal. Prefería mantener los equipos pequeños para que todos
estuvieran siempre hablando con los demás. Heart eligió el tipo de personas que asumían la
responsabilidad personal de lo que hacían. Y aunque Heart toleraba la idiosincrasia, evitaba los “casos
mentales” egocéntricos, por muy inteligentes que fueran.
Al reunir el equipo de BBN para la propuesta ARPA, Heart se aseguró de contratar ingenieros con
todas las habilidades necesarias para una empresa tan ambiciosa. Kahn, por ejemplo, fue un
teórico consumado. Él, más que nadie en BBN, entendía los problemas asociados con el envío de
información a través de líneas telefónicas y tenía ideas claras sobre los mejores mecanismos de control
de errores. Ornstein era un perfeccionista y se notaba en el hardware que construía, mientras
que Walden traía consigo tanto su conocimiento de los sistemas en tiempo real como su decidida
voluntad de trabajar largas horas. Cosell tenía la capacidad de profundizar en programas de software
complejos y encontrar errores más rápido que nadie en BBN.
Debido a esto, Cosell era una de las pólizas de seguro humano de la compañía: los proyectos
serían trabajados en equipos, pero cada gerente de BBN sabía que si su proyecto se metía en
problemas, podía poner a Cosell a trabajar y sucederían cosas sobrehumanas en un abrir y cerrar
de ojos. . Aunque aún quedaba mucho trabajo de diseño detallado, entre ellos los miembros del
equipo comprendieron las cuestiones técnicas más importantes.
Cuando el equipo comenzó, Heart ya sabía lo que le esperaba: cuatro semanas de trabajo las 24
horas del día. Se esperaba que Heart volviera a cenar todas las noches a las seis y media, y siempre
llegaba. Pero después de cenar desapareció en su estudio y no salió hasta mucho después de que
su familia se hubiera acostado.
Una decisión inicial importante fue qué hardware utilizar. La confiabilidad era, con diferencia, la principal
preocupación de Heart. Sus quince años en el Laboratorio Lincoln construyendo antenas y sistemas de
radar para el ejército le habían enseñado a preocuparse por la fiabilidad por encima de todo.
Intuitivamente, Heart creía que los estudiantes de posgrado que estarían tocando los IMP en las
universidades no podrían quitar las manos del equipo. Había sido estudiante y probablemente incluso
había hecho el mismo tipo de cosas que temía (diablos, sabía) que ellos intentarían hacer.
Hurgaban en la caja para ver cómo funcionaba.
Las opciones de Heart eran limitadas. La industria de las minicomputadoras era todavía relativamente
joven. Sus líderes fueron Digital Equipment y Honeywell. Desde el principio, el problema de confiabilidad
llevó a Heart a preferir la nueva Honeywell DDP516, la máquina alojada en un gabinete de acero de alta
resistencia. La Marina tenía fama de establecer rigurosos estándares de ingeniería. Y algunos miembros del
personal de BBN conocían a algunos miembros del personal de Honeywell, que fabricaron la máquina en
una planta no muy lejos de la ubicación de BBN en Cambridge. El 516 también ayudó a disipar el temor
de Heart de que los estudiantes de posgrado curiosos pudieran derribar la red con sus modificaciones. Podía
estar mucho más tranquilo sabiendo que los IMP estarían alojados en una caja construida para resistir una guerra.
La funcionalidad de la sofisticada capacidad de entrada/salida (E/S) de la computadora Honeywell

(la velocidad y eficiencia con la que podía comunicarse con dispositivos externos como módems)
también ayudó a impulsarla a la cima de la lista. Como el manejo del tráfico de E/S era la función principal
del IMP, una máquina con una buena estructura de E/S era absolutamente esencial.
Poco después de escribir la propuesta, Dave Walden comenzó a sentir que podría estar fuera de su
alcance. Como el primer programador que Heart trajo al proyecto, Walden reflexionó mucho sobre
cuestiones generales de codificación e hizo algunos de los gráficos originales que esbozaban en
forma de bloques el flujo lógico y la sincronización del programa. Walden había esbozado lo suficiente
del programa como para darse cuenta de que estaban emprendiendo algo difícil. Decidió que la propuesta
ARPA proporcionaría una buena excusa para reclutar a Will Crowther, el ingenioso programador para quien
Walden había trabajado en Lincoln, para liderar el esfuerzo del software. Walden no se mostró en absoluto
reacio a contratar a alguien por encima de él. Tenía suficiente confianza en sus propios talentos
como para hacer caso omiso de las preocupaciones sobre el orden jerárquico que podrían preocupar a
muchas otras personas. Los dos habían trabajado estrechamente en Lincoln y Walden estaba más feliz de
estar en un equipo con Crowther que sin él. Y además, Crowther fue excepcional.
Tener a Crowther en el equipo no sólo aumentaría las posibilidades de que el software funcione. Tener
a Crowther en BBN haría que el trabajo fuera más placentero. Crowther era tranquilo, era fácil trabajar
con él y, cuando se trataba de escribir código, era francamente inspirador. También era un buen
amigo y compañero de escalada de Ornstein. Crowther parecía concentrarse mejor mientras colgaba de
los marcos de las puertas con las yemas de los dedos, haciendo dominadas. Y era conocido por sus
garabatos matemáticos. Mientras otros pasaban el tiempo en largas reuniones dibujando garabatos y
florituras, Crowther llenó su página con una maraña de ecuaciones diferenciales.
Walden, Heart y Ornstein estaban bastante seguros de que Crowther no había sido del todo feliz en Lincoln
desde que Heart se fue. A Crowther le gustaba trabajar para Heart y, mientras trabajaba en
Con su corazón en Lincoln, se había acostumbrado a ver las cosas construidas. Después de que Heart se fue,
muchas de las personas que habían trabajado para él habían vuelto a realizar retoques menos productivos.
Ornstein llamó a Crowther y le dijo: "Willy, deberías venir a BBN", a lo que Crowther aceptó de inmediato.
En Crowther, BBN obtuvo una incorporación invaluable. Se especializó en producir piezas de código complejas
y bien escritas, que eran exactamente lo que se requería en el IMP. De hecho, escribir pequeños fragmentos de
código intrincados era uno de los mayores placeres de la vida de Crowther. Su código estaba entre los más
sencillos que cualquiera que haya trabajado con él haya visto jamás. Dado que los IMP debían estar conectados a
líneas telefónicas, con datos entrando y saliendo constantemente, la idea era que un paquete de datos llegara
a un IMP, se procesara e inmediatamente se enviara o se colocara en una cola para esperar su envío. girar, todo
en menos tiempo del que se necesita para chasquear los dedos. Cada instrucción tardaba una o dos
millonésimas de segundo (microsegundos) en ejecutarse. Dado que cada instrucción innecesaria consumía
uno o dos microsegundos adicionales, cada pequeña tarea o fragmento de código de software tenía que escribirse
con intensa frugalidad, utilizando la menor cantidad de instrucciones posible.
Un elemento central del diseño de la red fue la idea de que la subred de IMP debería funcionar de forma invisible.
Entonces, por ejemplo, si alguien sentado frente a una computadora host en UCLA quisiera iniciar sesión en una
computadora en la Universidad de Utah, la conexión debería parecer directa. El usuario no debería tener que
preocuparse por el hecho de que exista una subred. El efecto fue similar al de marcación directa en el sistema
telefónico, que liberó a quienes llamaban de la molestia de tener que esperar a que un operador
estableciera sus conexiones. Al igual que el laberinto de equipos de conmutación automatizados en una compañía
telefónica, los IMP debían ser “transparentes” para el usuario. Como lo describió Roberts en la convocatoria de
propuestas, "Cada host transmisor mira la red a través de su IMP adyacente y se ve conectado al host
receptor".
Para lograr esa transparencia, la red tendría que ser rápida, libre de congestión y extremadamente confiable. Estos
eran requisitos relativamente sencillos que Roberts había escrito en la solicitud de propuestas, pero nadie
esperaba que cumplirlos fuera fácil.
Sin embargo, una de las primeras cosas que descubrió el equipo de software de BBN fue que podían hacer
que el código procesara diez veces la cantidad de paquetes por segundo que requería Roberts. Antes de
hacer cualquier otra cosa, Crowther y Walden escribieron el código para el bucle interno (el corazón del programa)
y contaron el número de instrucciones. Roberts se habría contentado con un bucle interno de 1.500 instrucciones;
Crowther y Walden usaron 150. A partir de eso, los dos programadores calcularon qué tan rápido el IMP podría
procesar cada paquete. Con esa información, pudieron predecir cuántos paquetes se podrían mover por segundo.
"De hecho, nos sentamos y escribimos las ciento cincuenta líneas de código, las contamos y luego lo supimos",
dijo Crowther. Habían descubierto el núcleo.
"Asumimos la posición de que será difícil hacer que el sistema funcione", escribió BBN en tono evasivo en
su propuesta. De esta manera cautelosa, el equipo de BBN le hizo saber a Roberts que no daba por sentado
una tarea sin precedentes en su complejidad, revolucionaria en
concepto y lleno de detalles técnicos de viabilidad incierta. Sin embargo, la propuesta luego demostró
que BBN parecía haber resuelto el problema.
Cuando se terminó la propuesta, ocupaba doscientas páginas y le costó a BBN más de 100.000
dólares, lo máximo que la empresa había gastado jamás en un proyecto tan arriesgado. El equipo de
BBN había cubierto gran parte del diseño de los IMP que una gran fracción de todo el sistema ya
estaba claramente definida. La propuesta terminada de BBN fue más un anteproyecto que un
esquema. Sus ingenieros habían diseñado programas de prueba y comprobaciones periódicas de
rendimiento para los IMP y la red. Describieron cómo la red manejaría la congestión en los buffers (áreas
de almacenamiento en las máquinas que servían como áreas de espera y áreas de preparación para el
flujo de paquetes dentro y fuera de la red), y cómo se recuperaría de fallas de línea y de computadora.
Proporcionaron a ARPA diagramas de flujo que describían cómo el software IMP manejaría problemas
tan difíciles como la sincronización y la actualización continua de las tablas de enrutamiento.
Elaboraron cálculos, ecuaciones y tablas detallados que cubrían, entre otras cosas, los retrasos en
la transmisión y la puesta en cola de paquetes. Todo estaba ahí para que Roberts lo viera.
El equipo de BBN presentó su propuesta el 6 de septiembre de 1968, relativamente seguro de que

nadie más había preparado una oferta tan detallada como la suya. Años más tarde, cuando se preguntó a
las personas que trabajaron en la propuesta BBN cuánto tiempo llevó redactar el documento, algunos
dijeron honestamente que pensaban que habían tardado seis meses.
El equipo de Heart obviamente había hecho una cantidad impresionante de trabajo extra con palas,
resolviendo algunos problemas que Larry Roberts no esperaba ver resueltos. BBN tenía otra
ventaja: su tamaño relativamente pequeño. Roberts no quería lidiar con mucha burocracia y las otras
propuestas estaban plagadas de ella. El equipo que Raytheon estaba formando, por ejemplo, abarcaba
cinco niveles de gestión. Roberts se dio cuenta de que encontrar a la persona adecuada con quien hablar
sobre el más mínimo problema podía requerir una docena de llamadas telefónicas.
El equipo de BBN, por otro lado, tenía una jerarquía muy simple. Todos informaron a Heart, quien
repartió las tareas y se aseguró de que se hicieran. Heart tenía un jefe, pero parecía estar dándole
a Heart amplia libertad para hacer lo que quisiera con este proyecto.
La primera señal de que la oferta de BBN se estaba tomando en serio se produjo cuando Roberts
convocó una reunión para revisar partes de la propuesta. Heart, Crowther, Kahn y Ornstein, muy animados,
tomaron el tren a Washington. (Heart intentó, sin éxito, convencer a Crowther de que se pusiera algo en
los pies además de zapatillas de deporte). Durante la reunión, defendieron y ampliaron su propuesta.
Roberts probó, empujó y empujó a los ingenieros para ver si realmente habían pensado profunda y
exhaustivamente en el sistema. Y sus preguntas continuaron durante algunas semanas después.
"En cierto nivel, creo que el continuo interrogatorio de Larry nos hizo pensar en los problemas
y seguir completando los detalles del diseño de forma subliminal", recordó Ornstein. “Pero creo
que lo más importante fue que nos lo tomamos más en serio que los demás contendientes. Hicimos del
diseño nuestro problema e hicimos todo lo posible para encontrar soluciones en las que creíamos sin
ceder demasiado a las especificaciones que otros habían establecido”.
Pero en su mayor parte, lo único que podían hacer era esperar. Si Roberts tenía una propuesta favorita,
no iba a dejar que nadie lo supiera. Podrían pasar meses antes de que supieran algo definitivo.
A mediados de otoño todos volvieron a lo que habían estado haciendo antes del maratón de propuestas. El
tiempo volvió a ralentizarse. Crowther se dedicó a la espeleología, que, junto con la escalada en roca y la escritura de
códigos, era su pasión. Heart llegó a casa a la hora de cenar y no volvió a trabajar. Kahn era prácticamente el único
que, por costumbre, seguía trabajando hasta altas horas de la noche. Todos estaban ansiosos. "Personalmente
pasé de la certeza de que nuestra propuesta no podía ser derrotada", dijo Ornstein, "a la creencia de que no
había manera de que pudiéramos ganar, dado el tamaño de BBN en comparación con los otros contendientes".
A lo largo del proceso de evaluación, a medida que la competencia por el Procesador de Mensajes de
Interfaz se fue reduciendo, el equipo de BBN escuchó rumores a través de los rumores de ARPA, aunque nunca del
propio Roberts, quien permaneció como una esfinge. Naturalmente, dudaron mucho. En sus momentos más pesimistas,
los ingenieros de BBN se inclinaban a creer que, dado que Roberts conocía a muchos de ellos de Lincoln, podría
resultarle difícil, incómodo o imposible adjudicar el contrato a BBN. No obstante, ARPA hizo precisamente eso.
Cuando llegó a la oficina del senador de Massachusetts Edward Kennedy, justo antes de Navidad, la noticia
de que se había adjudicado un contrato ARPA de un millón de dólares a algunos chicos locales, Kennedy envió
un telegrama agradeciendo a BBN por sus esfuerzos ecuménicos y felicitando a la compañía por su contrato para
construir el “Procesador de mensajes interreligiosos”. .”
4
Dirígete hacia abajo en los bits
El día de Año Nuevo de 1969 fue la última vez que el grupo de Frank Heart pudo descansar durante bastante tiempo.
La semana siguiente, comenzó oficialmente el contrato para construir los primeros procesadores de mensajes
de interfaz. Por poco más de 1 millón de dólares, BBN construiría cuatro IMP; el primero debía presentarse en
UCLA antes del Día del Trabajo, seguido de uno cada mes hasta diciembre. En doce meses se suponía que la red
estaría operativa y con cuatro sitios en línea. El equipo de BBN ya había trabajado mucho para generar la propuesta.
Ahora, de cara al futuro, vieron al menos ocho meses más de trasnochadas y trabajo intensivo de ingeniería de
sistemas. Todavía quedaban muchos desafíos desconocidos, un punto que BBN destacó enfáticamente en su
propuesta. Además, todos los miembros del equipo de Heart tenían ideas diferentes sobre lo difícil que sería construir
los IMP.
Heart se encontró con una gran cantidad de escépticos (gente de compañías telefónicas y académicos en su
mayoría) que no creían que una red de conmutación de paquetes funcionara. Argumentaron que construir el
hardware no era realmente la parte difícil; más bien, hacer que todo funcione en conjunto.
la parte de sistemas—era el truco. Incluso si se pudiera integrar todo el hardware y software y demostrar la
viabilidad de una red informática, señalaron algunos, todavía no habría ningún beneficio para una empresa como
AT&T o IBM, no como propuesta comercial. ¿Quién, excepto unos pocos burócratas gubernamentales o
científicos informáticos, utilizaría alguna vez una red informática? No es que la informática tuviera un mercado de
masas como las cadenas de televisión o la compañía telefónica.
Durante las semanas previas a ganar la licitación, la mayor duda de BBN había sido si ARPA confiaría el
trabajo a una empresa tan pequeña. Los miembros del equipo de BBN sabían que ahora había mucho en
juego. Si los IMP no funcionaran, las redes y la conmutación de paquetes caerían en el olvido de los
experimentos fallidos. Algunas personas (sobre todo otros postores)
expresó su asombro de que el pequeño BBN hubiera ganado el contrato. "Este tipo de trabajo de sistemas
grandes simplemente no parecía ser del agrado de BBN", dijo un competidor.
En general, Heart ignoró a los detractores, aunque a él también le preocupaban ocasionalmente los
desafíos técnicos que se avecinaban. Para ser efectiva, una red de datos tendría que enviar paquetes
de manera confiable, a pesar de los errores inevitablemente introducidos durante la transmisión a través
de líneas telefónicas comunes. Los oídos humanos toleran el ruido de las líneas telefónicas, que a
menudo es apenas audible, pero las computadoras que reciben datos son quisquillosas con el ruido, y el más
mínimo silbido o estallido puede destruir pequeños fragmentos de datos o instrucciones. Los IMP
tendrían que poder compensar.
Luego hubo que anticipar cortes de circuito, especialmente si el experimento de cuatro nodos se
expandió de costa a costa como lo imaginó ARPA. Un mal tiempo en algún lugar, una tormenta en el
Medio Oeste o una tormenta de nieve en Nueva Inglaterra, dejaría sin servicio una línea telefónica de larga
distancia que transporta tráfico de datos de red. No se pudieron evitar breves interrupciones en el
servicio y los IMP tendrían que solucionarlas. Además de eso, en las mejores condiciones, había una matriz
enormemente complicada de problemas de enrutamiento que resolver. El equipo de Heart tuvo que
evitar que los mensajes circularan interminablemente en la red, rebotando de nodo en nodo sin llegar nunca
a su destino final. Finalmente, el equipo tuvo que considerar la posibilidad de atascos en los buffers de
memoria. Los mensajes podrían tener un máximo de 8.000 bits; Los IMP debían dividir dichos mensajes en
una secuencia de paquetes con un tamaño máximo de 1.000 bits cada uno. Un paquete contendría el
equivalente a aproximadamente dos líneas de texto en esta página.
El sistema tenía que entregar paquetes y mensajes dentro de las especificaciones de tiempo que Roberts
había establecido: medio segundo para que un mensaje pasara de cualquier host de origen a cualquier
host de destino a través de la subred IMP. Significaría procesar datos a velocidades del orden de cien
mensajes por segundo, lo que ciertamente era posible, aunque sincronizarlo todo sería difícil.
Como si los desafíos técnicos no fueran suficientes, el cronograma del proyecto de la red ARPA iba por la
vía rápida; El calendario fijado por Roberts estaba ligado al ciclo presupuestario y a las realidades
políticas que enfrentaba en Washington. Ocho meses no fueron suficientes para que nadie construyera la
red perfecta. Todos lo sabían. Pero el trabajo de BBN era más limitado que eso; era para demostrar que el
concepto de red podía funcionar. Heart tenía la suficiente experiencia como para saber que era necesario
hacer concesiones para lograr que algo tan ambicioso se hiciera a tiempo. Aun así, la tensión entre el
perfeccionismo de Heart y su impulso por cumplir los plazos siempre estuvo con él y, a veces, era evidente
para los demás como una contradicción abierta y no resuelta.
BBN enfrentó muchos otros problemas que habían dejado fuera de la carrera a otros postores y postores
potenciales. Ahora todos estos problemas pertenecían a Frank Heart.
Empezando
"Una cosa es que cuando te conectas a un enchufe en la pared y los electrones fluyen", dijo Bob
Kahn. "Otra cosa es cuando tienes que averiguar, para cada electrón, qué dirección toma". En opinión de
Kahn, esto resumía la dificultad de construir una red que conmutara paquetes de bits, y lo hiciera de forma
dinámica. Kahn sabía muy poco sobre diseño de hardware. Era un científico que realizaba
principalmente trabajos conceptuales sobre arquitectura y diseño de sistemas. Debido a que reflexionó
sobre los aspectos conceptuales más amplios del problema quizás un poco más profundamente
que sus colegas, le preocupaba más la complejidad de construir la red. Para Kahn, la red era más una
abstracción, perfectible y completa, que para los demás miembros del equipo, involucrados como
estaban en la programación y el cableado real de sus muchas partes.
El concepto de conmutación de paquetes abrió un rico universo en el que un ingeniero capacitado y

con orientación teórica como Kahn podía investigar una amplia gama de escenarios hipotéticos.
Los análisis de Kahn ya habían ayudado a dar forma al proyecto de la red ARPA. Kahn había
aportado ideas libremente a Larry Roberts, instándolo a lanzar el experimento de redes ARPA a gran
escala utilizando líneas telefónicas de larga distancia. Otras personas habían dicho que un experimento
a pequeña escala estaría bien para empezar, pero a Kahn le preocupaba que no se pudiera aprender
nada significativo de un experimento pequeño. Roberts estuvo de acuerdo y se decidió por una red
transcontinental de al menos diecinueve nodos.
Ciertamente se podría construir un experimento en red en un solo laboratorio, si así se quisiera.

Para entonces, Donald Davies finalmente había recibido el visto bueno y algunos fondos para hacer
precisamente eso en el Laboratorio Nacional de Física de Londres, utilizando líneas cortas, cada una de
cientos de metros como máximo. Kahn estaba seguro de que un experimento de red pequeña no
“ampliaría”, al menos no en términos prácticos. Razonó que los enlaces cortos en un laboratorio no
tendrían las mismas tasas de error y problemas en el mundo real que las líneas largas utilizadas en el sistema telefónico.
El verdadero objetivo era vincular a los científicos informáticos y, eventualmente, a otros usuarios de
computadoras, en todo el país. Por lo tanto, una red real tendría que cubrir miles de kilómetros y tendría
que diseñarse para manejar paquetes (y corregir errores de líneas telefónicas) a un ritmo mucho mayor
que cualquier red pequeña.
Roberts parecía confiar en el juicio de Kahn. Antes de que la solicitud de propuestas saliera a la calle y
BBN se convirtiera en postor, los dos hombres hablaban de vez en cuando. Una vez que Kahn
fue reclutado para contribuir al esfuerzo de propuesta de BBN, trabajó hasta altas horas de la mañana,
noche tras noche, ocasionalmente en la sala de estar de Severo Ornstein, ayudando a diseñar el
sistema para la oferta de BBN. El trabajo dio sus frutos, BBN obtuvo el contrato y Kahn ya había decidido
volver a su propio trabajo de investigación después de Navidad.
Pero a medida que avanzaba el año nuevo, Kahn comenzó a tener dudas. Las cuestiones técnicas
eran complicadas. Quizás debería quedarse hasta la implementación. No podría doler. Además,
Kahn estaba ansioso por aprender más sobre el lado del hardware de Ornstein. Y mudarse a la tienda
de Heart era la única manera que tenía Kahn de continuar su propia investigación de redes, o eso le
hicieron creer las personas que dirigían BBN.
Jerry Elkind, el hombre a quien le reportaban Heart y Kahn, instó a Kahn a unirse al grupo IMP
porque Heart ahora tenía el único contrato en BBN dedicado específicamente a la creación de
redes. Aunque continuó informando a Elkind, Kahn entró en los sistemas de Heart.
grupo. Pronto se encontró recogiendo su oficina y cruzando el puente peatonal BBN desde el refugio académico de
Bolt hacia el almacén rediseñado donde el grupo de jóvenes que habían comenzado a llamarse a sí mismos
los "Chicos IMP" ya estaban trabajando duro. (Y eran chicos. De acuerdo con las normas de la época, con la
excepción de la secretaria de Heart, las personas que diseñaron y construyeron la red ARPA eran todos
hombres. Pocas mujeres ocupaban puestos en informática. La esposa de Heart, Jane, había renunciado su
trabajo de programación en Lincoln para criar a sus tres hijos).
El equipo que Heart había reunido sabía cómo hacer cosas que funcionaran, si no perfectamente, sí lo
suficientemente bien. Eran ingenieros y pragmáticos. Durante toda su vida habían construido cosas, conectado
cables y hecho realidad los conceptos. Su espíritu era utilitario. En esencia, toda ingeniería se reduce a hacer
concesiones entre lo perfecto y lo viable.
Ahora importaba la funcionalidad, no la elegancia o la belleza. A diferencia de, digamos, los finos relojeros suizos,
cuya ingeniería y arte son inseparables en un reloj de 40.000 dólares, el equipo de Heart separó naturalmente
el arte del oficio de construir una computadora confiable. Mirando hacia abajo, los ingenieros menores con egos
más grandes podrían intentar lucirse, infundir arte al mecanismo, crear alguna maravilla de la ingeniería, una
maravilla de complejidad con incrustaciones de oro y filigranas. La fuerza interior del equipo de Heart
era su moderación, su madurez. Este no era un lugar para la artesanía exclusiva. "Había una infinidad de formas
en las que podíamos equivocarnos, y un número sustancial de formas en las que podíamos hacerlo bien", dijo
Walden, el primer programador al que Heart contrató. "Los buenos ingenieros encuentran una de las formas de
hacerlo bien".
Los sistemas de radar en tiempo real, los sistemas de detección sísmica de pruebas de bombas atómicas
y terremotos, y los demás sistemas en los que Heart, Ornstein, Crowther y Walden habían trabajado en el
Laboratorio Lincoln habían sido más complicados que el IMP. Años más tarde, algunas personas dirían que el
IMP no era más que un gran dispositivo de E/S y, en realidad, muy simple.
Para el usuario, el IMP debía ser tan simple como una toma de corriente o un interruptor de pared que hiciera su
trabajo sin llamar la atención. Por otra parte, construir el IMP para que funcionara tan bien y tan discretamente
como un enchufe o interruptor doméstico fue precisamente el desafío.
El equipo de software había estado trabajando en estrecha colaboración desde la propuesta. Cada miembro
tenía un rol específico. Crowther trabajó en las comunicaciones de IMP a IMP, Walden se concentró
en los problemas de IMP a host, mientras que Cosell trabajó en herramientas de desarrollo y depuración.
Willy Crowther, de treinta y dos años, tranquilo pero obstinado, era el alma del equipo. En las primeras semanas
de 1969, Crowther colgó mucho de los marcos de las puertas de las oficinas.
Todos los que lo rodeaban simplemente aceptaron el comportamiento como la forma en que Willy se calentaba. Le
ayudó a fortalecer sus manos para escalar rocas y pareció ayudarle aún más a pensar.
El estilo de Crowther, reconocido por el resto del equipo, era parecer como si no estuviera haciendo nada
durante días, o simplemente haciendo un montón de dominadas con el marco de la puerta, antes de finalmente
liberar en un torrente lo que se había estado formando en su mente.
Si Crowther y sus colegas confiaban en su programación y diseño de software, Ornstein confiaba igualmente
en dirigir el esfuerzo del hardware. Fue responsable del diseño de dispositivos de E/S de alta velocidad
que BBN planeaba agregar al Honeywell 516. El considerable esfuerzo que ya había invertido en la
redacción del
propuesta fue un tiempo bien empleado. Después de realizar sólo algunas mejoras y toques finales, el equipo
estaría listo para pasar a las fases de construcción y programación del hardware del proyecto. La
primera tarea de Ornstein fue llevar el diseño del hardware a un punto en el que pudiera acudir a Honeywell con
una serie de modificaciones detalladas al 516.
Después de eso, Honeywell comenzaría a construir los dispositivos de E/S especializados que el IMP necesitaba
para comunicarse con los hosts y otros IMP.
El equipo de IMP tuvo que decidir qué operaciones de red serían manejadas por el software de IMP y cuáles
estarían cableadas o integradas en el hardware de IMP. Las tareas simples que debían realizarse rápidamente
se manejaban mejor mediante hardware. Pero una vez diseñado y construido, un equipo era más difícil de modificar
que cualquier software. Por lo general, los chicos de IMP preferían las soluciones de software. Si se podía
hacer algo lo suficientemente rápido en software, lo hacían allí, diseñando el sistema para tener más
margen para revisiones posteriores.
En febrero, BBN había confirmado su contrato con Honeywell para la compra de los DDP516. En cuestión
de días, Honeywell entregó e instaló la primera computadora 516 en una habitación en la parte delantera del
complejo de BBN en Moulton Street. Esta máquina no era la versión modificada de grado militar encargada, sino
una 516 sencilla y lista para usar. Era un probador, la máquina de “desarrollo”, con la que los programadores
experimentarían mientras se ponía a trabajar. Los programadores generalmente no están dispuestos (o no
pueden) llegar muy lejos en la escritura de código para una computadora específica hasta que el hardware
real en el que se ejecutará esté disponible. Ornstein acababa de comenzar el proceso de elaboración de todos
los detalles finales de las interfaces de E/S especializadas; Podrían pasar semanas antes de que Honeywell
pudiera poner esas interfaces a disposición para realizar experimentos.
Como prácticamente todas las computadoras de su época, la máquina Honeywell no tenía disco: ni disco
duro, ni disquete (los disquetes aún no se habían inventado). Tenía una memoria central: una matriz densa
de alambres de cobre finos como un cabello y anillos o núcleos de ferrita magnetizados, cada uno del tamaño
aproximado de una semilla de mostaza. El tamaño total de la memoria solicitada (12k) era minúsculo para
los estándares actuales. La cantidad de memoria en una computadora de escritorio a mediados de la década
de 1990, si consistiera en núcleos de ferrita, ocuparía un área aproximadamente del tamaño de un campo de fútbol.
Una ventaja interesante de la memoria central es su naturaleza no volátil. Si apagas la máquina mientras
estás trabajando en algo, no perderá su lugar; volvería a continuar donde lo había dejado. El equipo de Heart
también había diseñado una función de reinicio automático: si fallaba la energía, se suponía que la
máquina se detendría por completo y luego se reiniciaría automáticamente cuando regresara la energía. Con
la memoria central, la máquina se reiniciaría al comienzo del programa tan pronto como se restableciera la
energía.
La única vez que era necesario recargar un programa era cuando se publicaba una nueva versión o cuando algún
problema de hardware o software provocaba que se sobrescribiera la memoria. En estos casos, el programa IMP
se recargaría desde un lector de cintas de papel, un dispositivo electromecánico torpe que irradiaba
luz desde una bombilla incandescente a través de una cinta de papel que pasaba a través de una línea de
fotocélulas. El IMP tenía otras medidas de autosuficiencia, una de las cuales se llamaba cronómetro de “vigilancia”.
“Si el programa se descontrolaba”, explicó Heart, un pequeño temporizador de la máquina se pondría a cero (pero
un programa en buen estado lo reiniciaría continuamente). Si el temporizador llegaba a cero y se
apagaba, se suponía que el IMP había
un programa destrozado. Luego activaría un relé para encender el lector de cintas de papel, le daría un tiempo
para que se calentara y luego recargaría el programa. BBN enviaría a cada máquina una copia de una cinta
que tenía tres copias de todo el programa operativo IMP en secuencia, dando a cada IMP la oportunidad de
realizar tres recargas automáticas antes de que alguien tuviera que ir a rebobinar la cinta. Más tarde, BBN
inventaría un plan aún más ingenioso para recargar los IMP bloqueados desde los IMP vecinos más cercanos
y comenzar de nuevo. Todas estas eran características inusuales en ese momento.
Los chicos de IMP se pusieron a trabajar en la escritura del código y, cuando terminaron, tendría unas seis mil
palabras. “Un programa pequeño”, dijo Heart. Hicieron toda su programación en lenguaje “ensamblador” Honeywell
516.
Las computadoras son mecanismos que siguen instrucciones. La programación en lenguaje ensamblador
requiere pensar en una gran cantidad de pasos diminutos y luego escribir las instrucciones para llevarlos a cabo.
Por ejemplo, digamos que quieres encontrar el ascensor. Un conjunto equivalente de instrucciones en un lenguaje
de alto nivel podría ser algo como esto: "Sal por la puerta, gira a la derecha, pasa la fuente de agua y estará a tu
izquierda".
El equivalente en lenguaje ensamblador comenzaría más así: “Encuentra tu pie izquierdo; Encuentra tu pie
derecho. Coloque su pie izquierdo delante de su pie derecho. Ahora coloque su pie derecho delante de su pie
izquierdo. Repita esto diez veces. Detener. Gira noventa grados a la derecha. Etcétera.
Programar en lenguaje ensamblador era pensar maniáticamente en el mecanismo. A los programadores les
resultaba fácil perder de vista el objetivo más amplio y les resultaba difícil escribir programas breves y
económicos. Los programadores no cualificados a menudo terminaban escribiendo programas en lenguaje
ensamblador que vagaban sin rumbo, como una desventurada expedición al Ártico en medio de una tormenta de nieve.
Crowther logró mantener los pasos detallados de la programación en lenguaje ensamblador en su cabeza sin
perderse. Pero siempre dibujaba grandes diagramas de flujo para poder imaginarlo todo a la vez. Un colega
comparó el proceso con el diseño de una ciudad entera mientras se realiza un seguimiento del cableado de cada
lámpara y de las tuberías de cada baño.
A veces, sin embargo, Crowther evitaba los diagramas de flujo y los hacía mentalmente.
Mientras que otros luchaban por aplicar las herramientas de programación rudimentarias de la época,
Crowther estaba operando en un plano superior.
La escritura del software IMP comenzó en las oficinas de los miembros del equipo de programación, donde cada
uno escribía código en un Teletipo Modelo 33 en un “editor” PDP1. Después de crear el código en el PDP1, se
transfirió en cinta de papel a la computadora Honeywell, donde se convirtió al lenguaje de máquina de Honeywell,
una tarea realizada por un programa conocido como ensamblador, que convirtió el código en 1s. y 0s el 516
podría entender. Luego, el código ensamblado se grabó en cinta de papel. Durante un tiempo, los
programadores intentaron usar el ensamblador que venía con el Honeywell 516, pero era tan ineficiente
que pronto lo abandonaron: Walden y Cosell pasaron catorce horas un fin de semana ensamblando el código del
sistema IMP, usando casi una caja entera, casi Media milla de cinta.
No mucho después de eso, Cosell escribió algo de código para modificar el ensamblador mucho mejor
en la computadora PDP1 de tiempo compartido de BBN al final del pasillo. Esto hizo posible que el PDP1
produjera cintas en lenguaje de máquina para el Honeywell 516. A partir de entonces, el equipo escribió
fragmentos de código IMP, los editó y los ensambló bajo el sistema de tiempo compartido del PDP1.
Una vez que estuviera satisfecho con el proceso de ensamblaje, el programador ordenaría al PDP1 que
grabara el código ensamblado en una cinta de papel y luego llevara la cinta de regreso al laboratorio donde
se encontraba el 516. Cargaría la cinta en el 516, la ejecutaría y esperaría a ver qué pasaba. Por lo
general, habría algunos errores y, por lo tanto, se repetiría el proceso.
Naturalmente, cuando uno de los programadores veía que sucedía algo interesante o peculiar mientras se
ejecutaba un nuevo código en el 516, los miembros del equipo se acercaban al evento y se paraban alrededor
de Honeywell hablando sobre el tema.
La mayoría de los chicos del IMP vivían cerca de Cambridge y les resultaba fácil entrar y salir del laboratorio a
cualquier hora. El restaurante chino original de la chef Joyce Chen estaba al lado de BBN, y eso ayudaba
cuando trabajaban hasta tarde, como solían hacer. Cosell y Walden bebieron mucha CocaCola para
mantenerse; Crowther nunca tocó esa cosa. Era notoriamente quisquilloso con la comida (cualquier cosa
más allá del nivel culinario de un simple sándwich de mortadela era un riesgo), lo que lo convertía
en un invitado o compañero de cena imposible.
Al principio del proyecto, se pidió a BBN que informara a un grupo de personal militar y de ARPA de alto
nivel en el Pentágono. Crowther estaba entre los que planeaban hacer el viaje en nombre de los IMP
Guys. Heart se puso nervioso sólo de pensar en lo que Crowther podría vestir para la sesión informativa.
La gente seguramente notaría sus pies, pensó Heart. La única vez que alguien recuerda a Crowther usando
zapatos que se podían lustrar fue el día en que se casó. Heart fue a Ornstein y le pidió que le dijera a
Crowther que no usara zapatillas en el Pentágono. Ornstein lo hizo.
"Willy, Frank dice que no deberías usar zapatillas en esta reunión".
Hubo un largo silencio al otro lado de la línea. Y luego la voz tranquila de Crowther.
"Dígale a Frank que han visto mis zapatillas en reuniones del JSAC [Comité Asesor de Servicios
Conjuntos] antes y que todo estará bien". Fue.
Crowther y Ornstein se encontraban entre los empleados más devotos de Heart. Pero les encantaba bromear
con el jefe cuando se presentaba la oportunidad. "Frank se tomó las cosas muy, muy en serio",
observó Ornstein.
Ornstein se opuso abiertamente a la guerra de Vietnam. En 1969, muchas personas que nunca habían
cuestionado su propia participación en proyectos de investigación patrocinados por el Pentágono
comenzaron a reconsiderarlo. Ornstein había empezado a llevar un prendedor en la solapa que decía RESISTIR.
¿El pasador también llevaba el? signo, para resistencia eléctrica, un símbolo pacifista popular para
los ingenieros eléctricos. Un día, antes de una sesión informativa en el Pentágono, Ornstein concibió un
nuevo uso para su pin. En las reuniones en el Pentágono, no era inusual que los hombres alrededor de la
mesa se quitaran las chaquetas y se arremangaran las camisas. Ornstein le dijo a Heart que iba a colocar su
botón de RESISTENCIA en la chaqueta de un general cuando nadie estuviera mirando. "Creo que a Frank
realmente le preocupaba que yo lo hiciera", dijo Ornstein. (Ornstein no lo hizo, pero sí usó su pin en la reunión).
Cuando los IMP Guys expusieron sus planes en Washington, se hizo evidente que la red ARPA
sería un híbrido de las ideas originales de Baran y Davies. La red ARPA utilizaría un esquema de
enrutamiento adaptativo que los IMP Guys habían desarrollado por su cuenta, pero que era similar
a la idea básica que Baran había esbozado. Sin embargo, a diferencia de la red teórica de Baran, la
red ARPA no tendría casi el mismo nivel de redundancia o número de enlaces a cada nodo. Los nodos
del esquema BBN normalmente estaban vinculados a dos nodos vecinos, ocasionalmente a uno o
tres. Tal como se concibió ahora, sólo dos enlaces fallidos podrían dividir o dividir la red en segmentos
aislados. Paul Baran había dicho que se podía construir una red con multitud de enlaces redundantes
a partir de piezas económicas; si una pieza fallaba, habría otras que la respaldarían. El bajo nivel de
redundancia en la red ARPA se acercaba más al plan de Davies. El enfoque de Heart fue hacer que
cada parte de la red fuera lo más sólida y confiable posible.
Durante el período de la propuesta, Crowther y Walden ya habían realizado un trabajo crucial, con
resultados sorprendentes. Primero, habían encontrado una manera de hacer que el enrutamiento
adaptativo funcionara de manera eficiente. También descubrieron que podían hacer que el sistema
funcionara mucho más rápido de lo que nadie imaginaba. Los observadores dijeron que su código
no funcionaría; Crowther y Walden sabían que así sería. Al escribir el “núcleo” de su programa (“la
parte muy pequeña que es lo único que importa”, como lo expresó Crowther), descubrieron cuán
pocos comandos realmente se necesitarían en un programa de software para extraer paquetes al
IMP. , averigüe dónde enviarlos y extráigalos en la siguiente línea.
Crowther y Walden rápidamente desarrollaron los algoritmos críticos: las reglas básicas para
resolver los problemas de procesamiento y enrutamiento de paquetes. Eso los llevó a
determinar que sólo se necesitarían ciento cincuenta líneas de código para procesar un paquete a
través de uno de los IMP. Pero sin una máquina real para probarlo, la ejecución del código tendría
que esperar. No obstante, tenían la buena sensación de que el IMP funcionaría.
Una tarea clave que preocupaba a Heart, pero que no tenía que encargarse, era el subcontrato con
AT&T. Era responsabilidad de Larry Roberts organizar las líneas de 50 kilobits (capaces de
transmitir aproximadamente dos páginas de texto por segundo) en cada sitio anfitrión para la fecha en
que los IMP estuvieran listos. Roberts entregó el trabajo a otra agencia del Pentágono, que ahora
trabaja con AT&T en los términos para la instalación y arrendamiento de las líneas, módems
y otros equipos de comunicaciones adecuados necesarios para formar enlaces en la red. La
conexión física de los IMP a la oficina telefónica local se realizaría mediante un cable telefónico normal.
dos pares trenzados de alambres de cobre envueltos en un cable que contiene alrededor de mil
pares trenzados más, con un equipo de terminación especial en cada extremo para soportar altas
velocidades de datos. Las líneas dedicadas y otros equipos debían estar instalados en los sitios de
California cuando llegaran los primeros IMP en el otoño. Heart sabía que la compañía telefónica
iba a tener que luchar para cumplir con sus obligaciones y se alegraba de que conseguir la
cooperación de AT&T no fuera su problema.
Roberts era una fuerza distante pero persistente, vital para el proyecto. Su estilo era mantenerse
apartado de los investigadores principales la mayor parte del tiempo. Siempre que se involucraba en
un proyecto, nunca hacía perder el tiempo a nadie. Él siempre expresó su punto y siguió adelante. La
gente de la creciente comunidad informática llegó a tener en alta estima a Roberts.
Fueron días estupendos para dirigir la Oficina de Técnicas de Procesamiento de Información en ARPA.
Con Taylor y Roberts allí, el presupuesto para la investigación informática siguió creciendo incluso cuando
el resto de los fondos de ARPA se recortaban debido al creciente coste de la guerra de Vietnam. Los
directivos de la IPTO podrían gastar dinero en las prioridades que ellos mismos eligieran.
Y con la misma facilidad podrían rescindir la financiación si no recibieran el tipo de cooperación
que querían de los contratistas.
Dar amplia autoridad a personas como Roberts era típico del estilo de gestión de ARPA, que se remontaba
a sus inicios. Tenía sus raíces en una profunda confianza de los científicos e ingenieros de
primera línea. En su lecho de muerte en 1969, Dwight Eisenhower preguntó a un amigo acerca de “mis
científicos” y dijo que eran “uno de los pocos grupos que encontré en Washington que parecían estar
allí para ayudar al país y no para ayudarse a sí mismos”. De hecho, muchos de los mejores científicos del
país, entre ellos Roberts, llegaron a considerar trabajar para la agencia como una responsabilidad
importante, una forma de servir.
Pero los administradores de ARPA no estaban bien pagados. Una vez, Ornstein se reunió con Roberts
en una reunión fuera de la ciudad y vio a Roberts conduciendo un pequeño auto de alquiler averiado.
Ornstein le preguntó por qué razón alquilaría semejante montón de cosas. Roberts murmuró algo acerca
de que Ornstein no entendía las reglas y los gastos del gobierno. "Siempre pensé que él estaba repartiendo
estos millones de dólares", dijo Ornstein. “No se me había ocurrido que en realidad él vivía, personalmente,
con un presupuesto bastante limitado. Personas como Larry se sacrificaron durante un tiempo para
conseguir un gran acelerador”.
Roberts fue tratado en muchos aspectos como si fuera miembro del equipo BBN, a pesar de que
estaba en Washington. No viajaba a Cambridge con frecuencia, pero su presencia se sentía constantemente.
Dado que solo unas pocas personas estaban trabajando en el proyecto en BBN, Roberts se sentó con
todos juntos cuando los visitó. Fueron conversaciones informales sobre su progreso, largas sesiones
finales de alto nivel. Como investigador principal y director del grupo, Frank Heart era el principal punto de
contacto de Roberts en BBN, pero Roberts también se mantuvo en estrecho contacto con Kahn.
Cada sitio era responsable de crear una interfaz personalizada entre el host y el IMP. Dado que se
trataba de ordenadores de distintos fabricantes, no había una sola interfaz que sirviera para todos los sitios.
Esto implicó un proyecto de desarrollo de hardware y software separado en cada sitio y no era algo que los
equipos anfitriones pudieran implementar de la noche a la mañana.
Los chicos de IMP tuvieron que escribir la especificación de host a IMP antes de que los hosts pudieran
comenzar a construir algo. La tarea más urgente de Heart era completar el diseño de BBN de la
especificación de host a IMP, para que la gente de UCLA pudiera comenzar a trabajar a tiempo para cumplir
con el cronograma de Roberts. Heart ya predijo dificultades para lograr que los sitios anfitriones
completaran su trabajo a tiempo. Sabía hasta qué punto los investigadores principales dependían de los
estudiantes de posgrado, y a Heart le preocupaba que el proyecto pudiera descarrilarse debido a
que un estudiante de posgrado no se había tomado el cronograma con suficiente seriedad.
Los días dedicados a discutir la especificación de host a IMP se convirtieron en semanas. Se hizo obvio que,
a menos que alguien del equipo de Heart se diera a la tarea de simplemente escribir la especificación,
se hablaría más y se escribiría poco. Kahn se encargó de redactar la especificación y sus colegas
estuvieron felices de permitírselo. Heart pensó que Kahn era el mejor escritor que tenía el grupo, por lo
que dio un paso atrás y dejó que Kahn produjera la especificación que se conoció como Informe BBN 1822.
Algunas personas pensaban que Heart se preocupaba excesivamente por posibles fallos de ingeniería.
Era un conductor muy defensivo cuando se trataba de ingeniería. Heart había aprendido ingeniería
cautelosa desde el principio de su mentor en el Laboratorio Lincoln, Jay Forrester, el inventor de la
memoria central. Forrester había inculcado la confiabilidad en las cabezas de toda una generación de
ingenieros del MIT. Por encima del costo, el rendimiento o cualquier otra cosa, la confiabilidad era su principal prioridad.
diseñe para ello, construya para ello, prepárese para lo peor y, sobre todo, no ponga su máquina en
condiciones de fallar. El mantra de Heart incorporó confiabilidad al IMP de mil maneras desde el
principio.
Se sabía que los fabricantes de computadoras tomaban atajos para competir en precios y construir
nuevas máquinas a tiempo. Casi siempre pagaban algún precio en términos de mayores tasas de
fracaso (errores y fallos informáticos), pero normalmente eso no arruinaba su reputación. Desde Roberts
hasta Heart, y en adelante, todos los chicos de IMP esperaban un estándar más alto en este proyecto. Una
red que funcione las veinticuatro horas del día exigiría un rendimiento sólido de los IMP construidos por
BBN. El imperativo aceptado era que los IMP harían todo lo posible para transmitir todos y cada uno
de los mensajes con precisión. Una línea puede fallar, incluso una máquina host puede fallar, pero los IMP
no deberían hacerlo. La fiabilidad fue, en cierto sentido, el principio fundamental de la red. La red ARPA
siempre reflejaría el carácter estable de Frank Heart.
Ornstein tenía fama de ser un capataz duro y era muy eficaz como examinador técnico. Su frase
característica era: "Soy sólo un tonto tipo hardware, ¡convénceme!". No lo soltaría hasta que la
explicación tuviera sentido para él. A menudo descubría algún punto débil oculto.
Muchas de las sesiones de planificación en BBN tuvieron lugar en la Weiner Room, una sala de
conferencias de techo alto con una gran mesa cuadrada y muchas pizarras. Estaba convenientemente
ubicado en una intersección de pasillos en medio de la división de sistemas de BBN, un cruce
entre la sala de computadoras 516, el comedor y la oficina de Heart. La Sala Weiner sirvió como
lugar de reunión habitual para los IMP Guys. El equipo de IMP era lo suficientemente pequeño, sus
oficinas lo suficientemente cercanas y el contacto entre los miembros del equipo lo suficientemente
frecuente como para que las revisiones formales del diseño fueran innecesarias. Hablaban en los pasillos,
se sentaban en las oficinas de los demás, debatían y compartían ideas constantemente. En la Sala
Weiner, se aplicaba tiza abundantemente y con frecuencia para explicar, diagramar, delinear, argumentar
y enseñar. Ornstein utilizó la sala para impartir una serie de conferencias informales en las que se
explicaron detalladamente el software y el hardware y, ocasionalmente, venían visitantes para
hablar sobre temas técnicos. Todo el equipo compartió información. “Todo el mundo lo sabía
todo”, como dijo Crowther.
Los miembros del equipo también escribieron una serie numerada de notas técnicas informales que
circularon entre ellos. Las notas no tenían un formato estricto pero siempre comenzaban con "The
IMP Guys'Notes". Escribieron sus ideas, las intercambiaron y luego, por lo general,
se reunieron para discutirlos. Las notas también le dieron a Heart una forma de monitorear su
progreso.
Las revisiones de Heart sobre el trabajo a medida que maduraba no se parecían en nada a las revisiones de
diseño tradicionales. Una revisión del diseño suele ser un evento importante en el curso de un
proyecto de ingeniería. Un equipo de ingeniería puede trabajar durante semanas preparando un diseño para
su revisión y luego reunirse para presentarlo, elaborarlo y debatirlo bajo el escrutinio de colegas e
ingenieros superiores. Las revisiones de Heart tendieron a ser ad hoc y continuas, lo que no quiere decir
que fueran fáciles. "Era como tu peor pesadilla para un examen oral realizado por alguien con habilidades
psíquicas", recordó Bernie Cosell, el experto en resolución de problemas de software del equipo. “Podía intuir
las partes del diseño de las que estabas menos seguro, los lugares que menos entendías, las áreas en
las que simplemente cantabas y bailabas, intentabas salir adelante, y arrojar una luz incómoda sobre las
partes que menos querías ver. Trabaja en ello, mientras prácticamente ignoras las partes de las que
estabas tan orgulloso por haber sido realmente definido y hecho bien”.
Al igual que las reuniones menos frecuentes con Roberts, las revisiones de diseño de Heart estaban destinadas
a "ayudar a superar las partes difíciles", dijo Cosell. Heart tenía un respeto implícito por las cosas que
hacían sus ingenieros y que funcionaban bien. Pero fue parco en sus elogios. Su actitud parecía ser: ¿Por qué
perder el tiempo con eso? Los ingenieros más jóvenes y menos experimentados podrían haberse sentido
devastados por la falta de comentarios positivos de Heart, pero los chicos de IMP eran un grupo
experimentado, muy unido y seguro de sí mismo, muy acostumbrado a las costumbres de Heart.
Debido a la insistencia de Heart en la confiabilidad y al análisis inicial de Kahn de esta área, se diseñó en el
sistema una gran cantidad de mecanismos de control de errores. Todo sistema de
comunicaciones es propenso a errores de transmisión causados por el ruido en los circuitos de
comunicación. Las voces que pasan por los teléfonos, una transmisión analógica, pueden ser confusas o
ambiguas, como cuando los sonidos de la “s” y la “f” se confunden. Las transmisiones digitales
también pueden distorsionarse: un “1” puede parecer un “0” y viceversa.
Los errores ocurren en ráfagas. Si un bit determinado tiene un error, la probabilidad de que los bits
circundantes tengan un error es mucho mayor de lo normal. A pesar de estos problemas, existen buenas
técnicas para detectar e incluso corregir errores digitales, y los IMP tendrían que confiar en ellas.
La corrección de errores digitales se basa en la idea básica de la “suma de verificación”, un número

relativamente pequeño que se calcula a partir de los datos en su origen, luego se transmite junto con los datos
y se recalcula en el destino. Si los números originales y recalculados no coinciden, ha habido un error en la
transmisión, a menos que quizás el propio hardware de verificación haya fallado, algo muy improbable.
Las sumas de comprobación aparecen en transmisiones de datos de todo tipo. Por ejemplo, cada pitido que
se escucha en la caja del supermercado significa que un pequeño láser ha escaneado un código de barras
y ha transmitido sus dígitos a una computadora donde se ha calculado la suma de verificación y se ha
determinado que es correcta. La máquina en la caja ha realizado algo de aritmética decimal sofisticada a
lo largo del camino barajando, multiplicando y sumando los dígitos escaneados, todo en un abrir y cerrar de
ojos. En la mayoría de los sistemas de supermercados, el resultado debe terminar en 0, la suma de control de
un solo dígito utilizada para todos los productos.
Si se escanea un producto y la computadora no emite un pitido, significa que la aritmética no se verificó.

Si la computadora tuviera una forma de corregir el error, emitiría un pitido en cada pasada y
ahorrar tiempo. Pero las técnicas de corrección de errores añaden costos al sistema, por lo que el cajero debe pasar
el artículo por el escáner nuevamente, tal vez dos o tres veces hasta que el código se transmita sin errores.
Los chicos de IMP enfrentaron un problema similar: si una suma de verificación detectaba un error de paquete
en la red, ¿cómo se debía manejar? ¿El IMP transmisor debería enviar el paquete nuevamente o el IMP receptor
debería aumentarse con hardware para corregir el error? En una red, la corrección de errores consume
espacio en los circuitos de comunicaciones y aumenta el gasto de hardware en los equipos de conmutación. En
consecuencia, el equipo de BBN decidió que si un IMP detectaba un error en un paquete, lo descartaría sin acusar
recibo. El IMP de origen, que aún posee un paquete duplicado y aún espera reconocimiento pero
no lo recibe, retransmitirá el duplicado.
Antes de emitir la solicitud de propuestas, Roberts tuvo que decidir el tipo de suma de control para los IMP.
¿Cuántos bits se le deben asignar y qué nivel de sofisticación debe tener? El requisito preciso, basado en un
número promedio de errores en las líneas telefónicas, fue difícil de determinar porque no había información concreta
disponible sobre las tasas de error en las líneas de alta velocidad a través de las cuales se enviarían los datos.
Aun así, era obvio que una suma de comprobación de 1 bit nunca serviría. Tampoco lo sería uno de 2 bits,
ni siquiera uno de 8 bits. Incluso una suma de comprobación de 16 bits puede no ser suficiente.
Kahn había documentado anteriormente que una suma de comprobación de 16 bits podría no ser lo suficientemente
potente para alcanzar el nivel deseado de confiabilidad en la red, especialmente dada la incertidumbre en el
rendimiento de errores de las líneas de alta velocidad. Kahn compartió con Roberts algunos cálculos
aproximados que sugerían firmemente que una suma de comprobación de 24 bits sería una opción mucho mejor,
señalando que los 8 bits adicionales añadían muy poco gasto al hardware. La suma de control fue una de las muchas
cuestiones técnicas sobre las que Roberts escuchó el consejo de Kahn, y un 24
La suma de comprobación de bits se escribió en la RFP. Más tarde, Kahn argumentó el mismo caso de manera
convincente ante Crowther y los demás, y los chicos de IMP decidieron que la suma de comprobación de 24 bits
era una pieza vital del sistema de control de errores.
Los ingenieros de BBN tenían una buena intuición sobre qué problemas resolver en hardware y cuáles en
software. Tenía sentido dejar que el hardware del IMP calculara la suma de comprobación, porque un cálculo de
software sería demasiado lento. El esquema final de detección de errores de IMP a IMP fue una combinación
inteligente de técnicas de ingeniería conocidas y otras inventadas por el propio equipo de BBN. Como dijo Crowther:
"Robamos ideas de cualquier lugar, pero la mayoría de las veces teníamos que desarrollar las nuestras".
El día de San Valentín de 1969, Cambridge fue azotada por una tormenta de nieve. Alrededor de dos docenas de
personas asistieron a una reunión que duró todo el día en BBN. Esta fue la primera reunión entre el equipo de
Heart y los investigadores y estudiantes graduados de los sitios anfitriones.
A través de los ojos cautelosos de Heart, esta multitud de estudiantes, en su mayoría graduados, parecía hambrienta
de tener en sus manos los IMP. Sospechaba que cuando ARPA decidió colocar los IMP en los sitios, los
investigadores esperaban tener otra computadora para jugar. Imaginó que querrían utilizar los IMP para todo tipo de
cosas: jugar al ajedrez o calcular sus impuestos sobre la renta. “Tomé una posición extraordinariamente rígida”,
recuerda Heart. “No debían
tocarlo, no debían acercarse a él, apenas debían mirarlo. Era una caja cerrada sin interruptores disponibles”.
Kahn todavía estaba trabajando arduamente en la especificación de la interfaz de host a IMP, por lo que no
estaba claro para los miembros del equipo de host exactamente qué se les pediría que construyeran.
Algunas personas de los sitios anfitriones pidieron ver qué tenía BBN en mente, pero los chicos de IMP no
habían decidido un plan entre ellos. Sobre ese tema no se resolvió mucho en la reunión.
Los estudiantes de posgrado decidieron compartir con BBN un plan que habían ideado para que los hosts
calcularan una suma de verificación de un extremo a otro. Esto proporcionaría una capa adicional de protección
contra errores en las comunicaciones de host a host. Fue diseñado para detectar varios errores imaginados,
incluido el posible mal ensamblaje de paquetes de mensajes por parte de los IMP.
Heart se angustió al escuchar esto, porque ralentizaría los hosts y haría que todo el sistema pareciera
lento. Tampoco le sentaba bien la idea de que los IMP pudieran pasar paquetes dañados a los anfitriones.
Los estudiantes argumentaron que la suma de comprobación de 24 bits de BBN no cubría los
caminos desde los IMP a las computadoras host, y que los bits viajaban "desnudos" entre las dos
máquinas. Heart aseguró a todos, en términos muy claros, que la suma de comprobación IMP sería
confiable. Quedaba por verse, y con el tiempo los estudiantes estarían más en lo cierto que en lo equivocado,
pero con la confianza de Heart en exhibición, los sitios anfitriones abandonaron sus planes de incluir una
suma de verificación en los protocolos del anfitrión.
Más problemática fue la idea de conectar varias computadoras host al IMP en cada sitio. Cuando Roberts
diseñó la red por primera vez, su idea era conectar una (y sólo una) computadora host a cada IMP. Sin
embargo, en la reunión del Día de San Valentín, los representantes de los sitios dejaron en claro
que querían conectar más de una computadora host a cada IMP. Cada centro de investigación tenía varias
computadoras y, si era posible, tenía sentido intentar conectar más de una máquina por sitio. Roberts envió
un mensaje a Cambridge de que BBN debía rediseñar el IMP para manejar hasta cuatro hosts cada uno.
Walden, Crowther y Cosell inventaron una forma inteligente de hacerlo.
Después del Día de San Valentín, los chicos de IMP realmente se pusieron a trabajar. Sus jornadas de trabajo
se prolongaban hasta bien entrada la noche. Heart, que vivía en el pueblo rural de Lincoln, intentaba llegar
a casa a tiempo para cenar, pero muchas veces no lo lograba. Para los demás era más fácil ir a casa a cenar
y volver al trabajo, o no volver a casa. Cuando estaba inmerso en el proyecto, Crowther se sentaba frente a
su terminal hasta quedarse dormido.
Ahora la verdadera presión recaía sobre Kahn. Pasó gran parte de los dos meses siguientes hablando por
teléfono con gente de los sitios anfitriones, trabajando en las especificaciones de la interfaz. Kahn se convirtió
en el principal punto de contacto de BBN con la comunidad de investigación anfitriona. Los investigadores lo
llamaban periódicamente para comprobar qué estaba pasando y cuál era el calendario, o simplemente para
transmitirle nuevas ideas.
A mediados de abril, Kahn terminó la especificación, un documento grueso que describe cómo una
computadora host debe comunicarse con un conmutador de paquetes, o IMP. "Se había escrito en parte
teniendo en cuenta lo que nos habían dicho que querían los anfitriones, y en gran medida teniendo en cuenta
lo que sería posible implementar y lo que tenía sentido para nosotros", dijo Walden. Un comité de representantes
de los sitios anfitriones lo revisó y le dijo a BBN dónde no lo hicieron.
Creo que funcionaría. La especificación fue revisada hasta alcanzar un diseño aceptable.
Los sitios anfitriones tenían algo que construir ahora. El equipo de UCLA, que quedaría primero,
tuvo menos de cinco meses para prepararse para la llegada de su IMP.
Heart había trazado una línea clara entre lo que manejarían los IMP y lo que harían los
anfitriones. "Desde el principio, Frank tomó la decisión, una decisión muy sabia, de establecer
un límite claro entre las responsabilidades del anfitrión y las responsabilidades de la red",
dijo Crowther. Heart y su equipo decidieron poner la “máxima separación lógica” entre el IMP y el
anfitrión. Tenía sentido conceptual y de diseño para ellos trazar la línea allí para evitar saturar o
saturar las funciones del IMP. Esto también hizo que la construcción de los IMP fuera más manejable.
Todos los IMP podrían diseñarse igual, en lugar de personalizarse para cada sitio. También evitó
que BBN quedara atrapado en el medio, teniendo que mediar entre los sitios host a través de los
protocolos de red.
BBN había acordado con Roberts que los IMP no realizarían ninguna función de host a host.
Ese fue un gran problema técnico. No existían estándares lingüísticos ni de longitud de
palabras, y hasta el momento nada que facilitara la comunicación entre los anfitriones. Incluso
fabricantes individuales, como Digital, construyeron una serie de computadoras totalmente
incompatibles.
Lo último que quería BBN era el dolor de cabeza adicional que suponía resolver los problemas
de host a host. Además, Roberts no quería darle a BBN ni a ningún otro contratista tanto control
sobre el diseño de la red. Roberts estaba decidido a distribuir las responsabilidades
de manera equitativa. Entre Roberts y BBN se llegó a un acuerdo: el IMP se construiría como un
mensajero, un sofisticado dispositivo de almacenamiento y envío, nada más. Su trabajo sería
transportar bits, paquetes y mensajes: desensamblar mensajes, almacenar paquetes, verificar si
hay errores, enrutar los paquetes y enviar acuses de recibo de los paquetes que llegan sin errores;
y luego volver a ensamblar los paquetes entrantes en mensajes y enviarlos a las máquinas
host, todo en un lenguaje común.
Los IMP fueron diseñados para leer sólo los primeros 32 bits de cada mensaje. Esta parte del
mensaje, originalmente llamada "líder" (y luego cambiada a "encabezado"), especificaba el origen
o el destino e incluía información de control adicional. El líder contenía los datos mínimos
necesarios para enviar y procesar un mensaje. Luego, estos mensajes se dividieron en paquetes
dentro del IMP de origen. La carga de leer el contenido de los mensajes recaería sobre los propios
anfitriones.
Las computadoras host hablaban muchos idiomas diferentes y la parte más difícil de hacer que la
red fuera útil sería lograr que los hosts se comunicaran entre sí. Los sitios anfitriones tendrían
que lograr que sus computadoras dispares se comunicaran entre sí mediante protocolos que
acordaron de antemano. Estimulada por ARPA, la comunidad anfitriona estaba haciendo un esfuerzo
organizado para comenzar a resolver esas cuestiones de protocolo, sabiendo que pasaría bastante
tiempo antes de que algo se resolviera definitivamente.
IMP Número 0
Un día de primavera, un camión de reparto de Honeywell giró por Moulton Street. En el interior estaba la
primera máquina 516 construida según las especificaciones de BBN. La computadora del tamaño de un
refrigerador fue sacada del camión y colocada en un muelle de carga en la parte trasera del edificio de
la división de sistemas y luego fue llevada a una sala grande, que pronto se conocería como la sala
IMP, adyacente al muelle. El equipo había convertido un almacén en un espacio para probar los IMP
agregando un piso elevado para computadoras, iluminación fluorescente brillante y aire acondicionado. La
habitación sin ventanas era donde pronto pasaría mucho tiempo el hombre más joven del equipo, Ben
Barker, de veintidós años.
Barker era un estudiante universitario cuya brillantez había llamado la atención de Ornstein en una de las
clases que impartía en Harvard. Cuando a BBN se le adjudicó el contrato ARPA, Heart le ofreció un
trabajo a Barker, y Barker tomó una licencia para aceptarlo.
Barker, al igual que Ornstein, era ingeniero de hardware y daba señales de convertirse en un experto en
depuración: alguien que podía rescatar un proyecto cuando llegara el momento. Fue puesto a cargo de
configurar cada IMP entregado por Honeywell y de depurar el hardware antes de que saliera del taller de BBN.
Esta primera máquina fue el prototipo (IMP Número 0), un 516 no reforzado que contenía la implementación
inicial de Honeywell de las interfaces BBN. Con la máquina en el medio de la habitación, Barker encendió la
computadora, enchufó todo y la encendió.
Barker había creado un probador y había escrito un código de depuración. Estaba ansioso por solucionar
cualquier error que tuviera la máquina. Sin duda habría algo que habría que arreglar, porque siempre lo
hubo; Los errores eran parte del proceso natural del diseño por computadora. Heart y todo el equipo
esperaban descubrir qué partes del diseño IMP funcionaban y cuáles necesitaban más atención.
Barker intentó cargar el primer programa de diagnóstico IMP en la máquina no probada. No pudo
hacerlo funcionar. Entonces cargó otro código y tampoco funcionó. Barker intentó algunas otras cosas y
descubrió que nada funcionaba. "La máquina no hizo nada útil", dijo. Hasta ahora, el primer IMP fue un
fracaso.
Antes del proyecto IMP, la gente de BBN y Honeywell interactuaba de manera informal y las relaciones
eran amistosas. En los días previos al proyecto IMP creció una sensación de trabajo en equipo. Honeywell
había dedicado un equipo de sistemas especiales a trabajar en el contrato BBN desde el primer día. A
petición de BBN, Honeywell había asignado a uno de sus técnicos exclusivamente la tarea de guiar la parte
del trabajo de Honeywell hasta su finalización.
Esto fue inusual. En general, los fabricantes de minicomputadoras como Honeywell no atendían mucho a
las demandas especiales de sus clientes. "La mayoría de las empresas de informática no crean ninguna
oferta especial", afirmó Heart. "O si lo hacen, es bajo gran presión". Los vendedores de
minicomputadoras buscaban un mercado amplio, mientras que los fabricantes de computadoras centrales
eran conocidos por tratar a los clientes como a la realeza. Nadie en el negocio de las minicomputadoras
se tomó mucho de la mano.
A raíz del grave fracaso del IMP Número 0, el jefe de hardware de BBN, Ornstein, comenzó a repasar el
diseño con el equipo de Honeywell. Descubrió que nadie en Honeywell parecía entender con mucho
detalle cómo se suponía que debían funcionar las interfaces diseñadas por BBN.
trabajar. Le sorprendió saber que los técnicos que construyeron la primera interfaz no entendían
realmente los dibujos. Honeywell no había intentado desarrollar ningún diagnóstico para probar el
diseño; simplemente había intentado producir una implementación fiel de los diagramas de bloques
que Ornstein había dibujado y que BBN había incluido en su propuesta a ARPA.
El problema fue que al proporcionar a Honeywell un conjunto de diagramas de bloques bastante
genéricos, BBN supuso que la familiaridad y experiencia de Honeywell con sus propias máquinas
permitirían al fabricante de computadoras anticipar cualquier problema peculiar con las
modificaciones solicitadas por BBN al modelo 516. Honeywell tenía su propio Módulos lógicos, sistema
de diseño propio. Pero en lugar de resolver los detalles esenciales en los planos, Honeywell
había construido la máquina de BBN sin verificar que las interfaces diseñadas por BBN, tal como se
dibujaron, funcionarían con el modelo base 516.
Por supuesto, ni BBN al dibujar los diagramas de bloques ni Honeywell al implementar el diseño tenían
todas las herramientas necesarias para crear un prototipo de IMP que funcionara perfectamente en la
primera pasada. Al construir nuevas computadoras, dijo Barker, la suposición operativa es que se
diseña algo que se cree que funcionará, se prepara el prototipo, se comienzan las pruebas y luego se
corrigen gradualmente los errores de diseño hasta que la máquina pasa la prueba. Habría sido una
casualidad de ingeniería si la máquina hubiera funcionado perfectamente de inmediato. Pero incluso en
una primera fase, el estado de este prototipo de máquina era inaceptable.
Si Ornstein estaba preocupado por el desempeño de Honeywell, Barker estaba francamente

nervioso. Como principal depurador, él era el responsable de hacer que la máquina realmente
funcionara. En esta etapa del proyecto IMP, las interfaces del 516, dijo, "no habrían estado ni
cerca de funcionar incluso si Honeywell las hubiera implementado correctamente".
Barker contemplaba semanas de trabajo concentrado por delante. De repente sintió que el peso
del programa se hacía más pesado. Si el equipo de hardware de BBN tuviera la intención de entregar
al equipo de programación de BBN una versión funcional del Honeywell 516 modificado en un futuro
cercano, de modo que Crowther, Walden y Cosell tuvieran tiempo para la depuración final de su código
operativo, entonces los especialistas en hardware lo harían. tener que apresurarse. Con la ayuda de
Ornstein, Barker tendría que "tomar lo que Honeywell había construido", dijo, "y descubrir cómo hacer
que realmente hiciera lo que se pretendía hacer".
La llegada del prototipo IMP en su estado inicial marcó un verdadero revés; corregir el rumbo llevaría
tiempo, y pronto quedaría muy poco de eso.
Armado con un osciloscopio, una pistola para enrollar cables y una herramienta para desenrollar cables,
Barker trabajaba solo en la máquina dieciséis horas al día. Los circuitos de la computadora se basaban
en bloques de clavijas, o placas envueltas en cables, que servían como puntos de conexión
centrales a los que se enrutaban cientos y cientos de cables. Había numerosos bloques de treinta y
cuatro pines en los que se conectaban las placas lógicas y que llevaban componentes para formar los
circuitos correctos. Después de descubrir dónde deberían ir realmente los cables, Barker tuvo que
desenvolver cada cable mal conectado y mal enrollado de su clavija. Los pasadores de cada bloque
tenían aproximadamente una pulgada de largo y estaban muy espaciados (1/20 de pulgada entre sí) en
una matriz cuadrada; Cada bloque parecía un lecho de clavos en miniatura con cables que entraban
y salían como si fueran Medusa. Una vez que determinó dónde se debían volver a conectar los cables correctos, Barker
Usé la pistola para enrollar cables para envolver cada cable con cuidado en su pasador correcto. Fue
un proceso largo, laborioso y delicado.
Para complicar las cosas, Barker tenía una leve parálisis en las manos. Trabajar con una pistola de alambre
requería mano firme y buena concentración. El estrecho espacio entre los pasadores, el peso de la pistola
de alambre y el tamaño de la boquilla de la pistola que tenía que deslizarse sobre un solo pasador en medio
de un pequeño bosque de pasadores, todo conspiraba en su contra. El riesgo estaba en colocar el cable en
el pasador equivocado o doblar o romper un pasador. Podrías destruir muchos buenos trabajos si no tuvieras
cuidado. Así que el apretón en las manos de Barker causó un gran revuelo entre los otros chicos del IMP
cuando Barker llevó su pistola de alambre a los bloques de pasadores dentro del IMP.
La mayor parte del cableado se realizó con la energía apagada. Cuando había que hacer algo con la
alimentación encendida, se hacía con pequeños clips que se deslizaban sobre las clavijas. Aquí, sin
embargo, existía un peligro muy real de provocar un cortocircuito y hacer estallar los circuitos.
Barker pasó meses depurando la máquina. Ornstein estaba supervisando las correcciones de
diseño en el prototipo y asegurándose de que fueran transmitidas a los ingenieros de Honeywell. La
próxima máquina que Honeywell debía entregar sería la primera 516 robusta con todos los errores de
diseño solucionados: IMP Número Uno destinado a UCLA. "La tarea era lograr que los diseños
funcionaran a tiempo para enviarse", dijo Barker. El verano estaba sobre ellos.
La cautela de Heart ante las hordas de estudiantes de posgrado curiosos llevó a BBN a
conceptualizar medidas de protección aún mayores para los IMP. Con el tiempo, una de las cosas más
creativas que hizo el equipo de Heart fue inventar formas de obtener datos operativos críticos de los IMP de
la red (leyendo los signos vitales de las máquinas) discretamente desde la distancia.
Heart quería poder sentarse en una terminal en Cambridge y ver qué estaba haciendo un IMP en Los
Ángeles, Salt Lake City o cualquier otro lugar. La implementación completa por parte de BBN de
herramientas de diagnóstico remoto y capacidades de depuración se convertiría más tarde en una gran ventaja.
Cuando la red madurara, el control remoto permitiría a BBN monitorear y mantener todo el sistema desde
un centro de operaciones, recopilando datos y diagnosticando problemas a medida que las cosas cambiaran.
Periódicamente, cada IMP enviaba a Cambridge una "instantánea de su estado", un conjunto de datos sobre
sus condiciones operativas. Se podían detectar cambios en la red, menores y mayores. El grupo de Heart
imaginó que algún día sería capaz de mirar a través de la red para saber si alguna máquina estaba
funcionando mal o alguna línea estaba fallando, o tal vez si alguien estaba entrometiéndose con las
máquinas.
No obstante, BBN aún no había logrado que el prototipo IMP llegara a un estado en el que pudiera ejecutar
código operativo. Y el equipo de programación (Crowther, Walden y Cosell) se estaba moviendo ahora hacia
un territorio difícil: el diseño de un sistema de enrutamiento flexible o "dinámico", que permitiera enrutamiento
alternativo, de modo que los paquetes fluyeran automáticamente alrededor de nodos y enlaces con
problemas. Un esquema de ruta fija habría sido sencillo: se enviaría un paquete con instrucciones claras
para viajar a través de los puntos x, y y z del mapa. Pero si el punto y fuera eliminado, todo el tráfico se
paralizaría. Y eso frustraría una de las ventajas de una red con múltiples enlaces y nodos.
La solicitud original de ARPA especificaba el enrutamiento dinámico, sin ofrecer ninguna pista sobre cómo
hacerlo funcionar. Crowther había encontrado una manera de hacerlo. Estaba construyendo un sistema de
tablas de enrutamiento dinámico que se actualizarían aproximadamente cada fracción de segundo. Estas
tablas indicarían a los IMP en qué dirección reenviar cada paquete que aún no había llegado a su destino. Las
tablas de enrutamiento reflejarían condiciones de la red como fallas de línea y congestión, y enrutarían los
paquetes de la manera más corta posible. Hacer que este diseño realmente funcionara parecía un problema
alucinante, hasta que a Crowther se le ocurrió un conjunto de código simple y perfecto. Crowther “siempre tuvo
la cabeza gacha”, como describió Ornstein el talento asombroso e intuitivo de Crowther.
El algoritmo de enrutamiento dinámico de Crowther era una pieza de poesía en programación. "Era
increíblemente minimalista y funcionó asombrosamente bien", observó Walden. Sus colegas consideraban a
Crowther como parte de la fracción superior del 1 por ciento de los programadores del mundo. En ocasiones,
el elegante minimalismo del código de Crowther no fue suficiente para manejar la complejidad de los sistemas
del mundo real. Otros programadores tendrían que perfeccionar lo que Crowther había creado. Pero sus ideas
centrales eran, en la mayoría de los casos, brillantes. “La mayoría de nosotros nos ganamos la vida manejando
los detalles resultantes del uso que Will hace de su cerebro”, observó Walden.
El control de flujo fue otro desafío de programación. Pero cuando Kahn miró el código de Crowther y vio cómo
había implementado el control del flujo de paquetes de un lado de la red al otro, se preocupó. Los mensajes
entre hosts debían ser transmitidos por la subred a través de "enlaces" lógicos. La subred aceptaría un mensaje
a la vez en un enlace determinado. Los mensajes en espera de ingresar a la subred se almacenaban en un
búfer de memoria (un área de espera dentro de la máquina), en una cola. El siguiente mensaje no se
envió hasta que el IMP emisor recibió un acuse de recibo (similar a un acuse de recibo) que decía que el
mensaje anterior había llegado sin errores al host de destino. Cuando se borraba un enlace y se podía
enviar un nuevo mensaje, la subred notificaba al IMP emisor mediante una señal de control especial que
los ingenieros de BBN llamaron Listo para el siguiente mensaje, o RFNM (pronunciado RUFFnum). Los
mensajes en los buffers del servidor emisor, esperando a que se borraran los enlaces, eran como clientes en un
restaurante esperando mesa; Los RFNM eran el equivalente al anuncio del maître d: "Tu mesa está lista".
Esto significaba que era imposible enviar un flujo continuo de mensajes a través de un único enlace a través
del sistema de un host a otro. RFNM era una estrategia de control de congestión diseñada para proteger
los IMP de la sobrecarga, pero a expensas de reducir el servicio al host. Kahn había estudiado el
problema del control de la congestión incluso antes de que comenzara el proyecto de la red ARPA. Su
reacción a la solución de Crowther fue que los enlaces y los RFNM aún permitirían una congestión fatal de las
arterias de la red. Las reservas del IMP se llenarían, afirmó. Tendría mensajes incompletos en los IMP
receptores esperando a que lleguen sus paquetes finales para poder reensamblar el mensaje completo, y
no habría espacio para que lleguen los paquetes.
El escenario de bloqueo del reensamblaje de Kahn tiene un análogo en el negocio del transporte marítimo.
Supongamos que un concesionario Toyota en Sacramento solicita juegos de bloques de motor y pistones
de repuesto a un almacén en Yokohama. Ambos elementos juntos son esenciales para los trabajos que el
distribuidor tiene entre manos. En el puerto de Yokohama, los cargueros cargan grandes contenedores, de todos modos
tamaño, lleno de productos de todo tipo. Los bloques de motor y los pistones terminan en
barcos separados. Cuando el contenedor de bloques de motor llega a San Francisco, se
descarga en un almacén de contenedores cuyo contenido también son envíos parciales que esperan
la llegada de otras piezas antes de ser enviados: componentes para televisores, bloques de clavijas
para pianos, etc. Cuando llega el carguero con los pistones, encuentra el almacén lleno. Todos
los barcos posteriores tienen el mismo problema: nadie puede descargar; nada puede salir del
almacén. Punto muerto. ¿Solución? El transportista de Yokohama acepta llamar con anticipación
la próxima vez para reservar espacio para todos los contenedores que van juntos. Si no hay espacio
disponible, espera hasta que esté disponible antes de realizar el envío.
Kahn también predijo otro tipo de punto muerto que podría provocar la pérdida de paquetes. Dijo
que ocurriría con mucho tráfico dentro de la subred cuando los buffers de un IMP se llenaran con
paquetes enrutados a otro, y viceversa. Se produciría una especie de enfrentamiento en el que
ninguno de los dos podría aceptar los paquetes del otro. De la forma en que se había escrito el
software de enrutamiento, los IMP descartarían los paquetes.
Kahn y Crowther debatieron extensamente la cuestión del estancamiento. En puntos como estos,
las opiniones conceptuales de Kahn entraron en conflicto abierto con la inclinación pragmática del
resto de los tipos IMP y abrieron un amplio desacuerdo entre ellos. El resto del equipo sólo quería que
la red estuviera en funcionamiento según lo previsto. A medida que la red creciera, tendrían tiempo
para mejorar su rendimiento, resolver problemas y perfeccionar los algoritmos.
Pero Kahn persistió. "Pude ver cosas que para mí eran defectos obvios", dijo. "El más obvio fue
que la red podría bloquearse". Kahn estaba seguro de que la red se bloquearía y se lo dijo a Heart
y a los demás de inmediato. Discutieron con él.
"Bob estaba interesado en la teoría de las cosas y las matemáticas, pero en realidad no estaba
interesado en la implementación", dijo Crowther. Crowther y Kahn comenzaron a hablar sobre el
tema y los dos tuvieron lo que Crowther describió como “pequeñas grandes peleas”. El esquema
de control de flujo no fue diseñado para una red enorme, y con una pequeña cantidad de nodos,
Crowther pensó que podrían arreglárselas.
Heart pensó que Kahn se estaba preocupando demasiado por condiciones hipotéticas e
improbables de la red. Su enfoque fue esperar y ver. Algunos de los demás pensaron que Kahn
no entendía muchos de los problemas con los que estaban lidiando. “Algunas de las cosas que
sugería eran descabelladas, simplemente incorrectas”, dijo Ornstein. Kahn quería ver simulaciones
del tráfico de red en una pantalla. Quería tener un programa que mostrara paquetes moviéndose a
través de la red. De hecho, los paquetes nunca se moverían a una velocidad humanamente observable;
harían "zipzip" en microsegundos y milisegundos. “Dijimos, 'Bob, nunca entenderás los problemas si
lo miras de esa manera'”. Los otros chicos de IMP respetaban a Kahn, pero algunos creían que iba en
la dirección equivocada. Poco a poco le fueron prestando menos atención. “La mayoría de nosotros
en el grupo estábamos tratando de quitarnos a Kahn de encima”, dijo Ornstein.
Heart rechazó la sugerencia de Kahn de utilizar una simulación. Heart odiaba ver a su equipo
de programación dedicar tiempo a simulaciones o escribir cualquier cosa que no fuera código operativo.
Ya estaban distrayéndose con otra cosa que a él no le gustaba: crear herramientas de software. El
corazón temía un retraso. A lo largo de los años había visto a demasiados programadores cautivados.
por la construcción de herramientas, y había dedicado toda su carrera a impedir que los ingenieros
jóvenes hicieran cosas que pudieran hacer perder dinero o tiempo. La gente de la división de Heart sabía que
si le pedían permiso para trabajar horas escribiendo editores, ensambladores y depuradores, encontrarían
una fuerte resistencia, tal vez incluso una pelea a gritos. Así que nadie preguntó nunca; simplemente lo
hicieron, construyendo herramientas cuando pensaron que era lo correcto, independientemente de lo que
pensara Heart. Este era el software que eventualmente necesitarían cuando llegara el momento de probar el
sistema. Todas eran piezas de programación personalizadas, diseñadas específicamente para el proyecto
ARPA.
Cuando el verano llegó a su punto máximo, surgió un problema preocupante: BBN todavía estaba esperando
la entrega por parte de Honeywell del primer IMP de producción, con todas las interfaces depuradas
construidas según las especificaciones de BBN. El equipo de programación dejó de esperar y siguió
adelante con su trabajo cargando una máquina de desarrollo de grado inferior con un programa de simulación
que el equipo había diseñado para imitar las operaciones del modelo de producción IMP y sus interfaces de E/S.
Aún así, probar el software en la máquina real fue el enfoque preferido. Y cada vez que llegaba la máquina,
Barker primero necesitaba tiempo para depurarla. El tiempo que quedaba se estaba acabando. A
finales del verano, la máquina aún no había cruzado el muelle de carga de BBN.
Faltaban sólo unas semanas para la entrega programada del IMP a California, y la propia reputación de BBN
estaba en juego.
El bicho
Finalmente, aproximadamente dos semanas antes del Día del Trabajo, Honeywell sacó rápidamente el primer
516 IMP robusto de su taller y lo llevó a Cambridge. Tan pronto como la máquina tocó el suelo en BBN, Barker
estuvo listo para trabajar en ella. Encendió el IMP Número Uno en la trastienda.
Barker cargó el código de diagnóstico IMP. Cuando intentó ejecutarlo, no pasó nada. La máquina no respondió.
Tras una inspección más cercana, era evidente que la máquina que recibió BBN no era la que había
pedido. Este 516 tenía pocas de las modificaciones que Barker y Ornstein habían elaborado minuciosamente
al depurar el prototipo; de hecho, estaba cableado tal como lo había sido el prototipo disfuncional original.
Con la fecha límite acercándose, Barker sólo tenía un recurso: arreglarlo en BBN. Esta vez al menos ya
sabía dónde debía ir cada cable. Con la máquina ubicada en medio de la gran sala, Barker se puso a
trabajar implementando todas las modificaciones de diseño necesarias para convertirla en un IMP funcional.
A los pocos días, Barker había conseguido que la máquina cobrara vida. Logró activar las interfaces del
IMP, tras lo cual la computadora comenzó a fallar a intervalos aleatorios. La aleatoriedad de los accidentes
fue inusualmente mala. Los problemas intermitentes de este tipo eran el diablo. El IMP funcionaría entre doce
y cuarenta horas seguidas, luego moriría y estaría en algún lugar "fuera de los bosques". ¿Qué hacer?
Ornstein recuerda: "No podíamos entender qué diablos estaba pasando".
A medida que se acercaba el Día del Trabajo, presionaron al IMP, sometiéndolo a tantas pruebas duras como
fuera posible. Podría funcionar bien durante veinticuatro horas y luego morir inexplicablemente. Barker
buscaba una pista, perseguía lo que parecía ser un problema, lo arreglaba y aun así la máquina seguía funcionando.
estrellarse de nuevo. Faltando solo unos días para la fecha límite de entrega, parecía que no iban a lograrlo.
Barker, que había estado cuidando la computadora, sospechaba que el problema estaba en la cadena de distribución
de la máquina. Fue sólo una corazonada.
El IMP tenía un reloj utilizado por el sistema operativo para mantener el tiempo en la máquina, no como lo harían
los humanos marcando segundos, minutos u horas, sino contando el tiempo en 1
incrementos de microsegundos (un millón de tics por segundo): rápidos para su época, pero cien veces más
lentos que las computadoras personales actuales. Este reloj proporcionó un marco en el que operaba el IMP y
regulaba las numerosas funciones de la computadora de forma sincrónica. En un sistema de comunicaciones,
los mensajes llegan sin previo aviso; Las señales interrumpen la máquina de forma asíncrona. Como una
llamada telefónica en medio de una cena, un paquete entrante aparece según su propio horario en la puerta del IMP
y dice: "Llévame ahora".
La computadora tenía un sofisticado sistema para manejar las interrupciones entrantes de manera metódica,
para no alterar el funcionamiento sincrónico de todas sus funciones. Si no se diseñan adecuadamente, estos
sincronizadores pueden verse afectados por una señal entrante que se produce en el momento equivocado.
Los errores del sincronizador son raros. Pero cuando ocurren y el sincronizador no responde adecuadamente a
una interrupción, las consecuencias son profundamente perturbadoras para el funcionamiento total de la
máquina. Se podría llamarlo un ataque de nervios; Los informáticos tienen otro término para esto: el
sincronizador entra en una condición "metaestable". "En tales circunstancias", dijo Ornstein, "la máquina
invariablemente muere en un estado de confusión irremediable, diferente cada vez".
Ornstein conocía muy bien los errores del sincronizador. Había solucionado el problema en la computadora que él y
Wes Clark habían construido unos años antes en St. Louis. Ornstein fue el autor de algunos de los primeros
artículos publicados sobre el tema y fue una de las pocas personas en el mundo que realmente tuvo alguna
experiencia con este duende en particular.
Su imprevisibilidad hizo que los errores del sincronizador estuvieran entre los más frustrantes debido a la
ausencia de cualquier patrón reconocible en los bloqueos resultantes. A diferencia de la mayoría de los otros
problemas que podrían causar fallas en las computadoras, un error en el sincronizador prácticamente no
dejó evidencia forense útil que pudiera señalar al diagnosticador el problema. De hecho, la ausencia de pistas fue
una de las más útiles. Además, los fallos causados por este error eran tan poco frecuentes (sólo una vez al
día, incluso en pruebas de calibre completo), que era imposible detectar ninguna evidencia en un osciloscopio. Sólo
los depuradores más astutos tenían idea de a qué se enfrentaban.
Éste parecía ser el problema que Ornstein y Barker tenían entre manos. Pero quién sabía, porque en realidad no
se podía rastrear. ¿Qué hacer ahora? El Honeywell 516 nunca se había utilizado en una aplicación tan exigente
como la red de conmutación de paquetes. Era una máquina rápida; Los chicos de IMP lo habían elegido
precisamente por sus capacidades de E/S. Probablemente nadie más vería el problema en una aplicación típica
de la computadora 516. “Si su máquina se estropeara una vez al año”, dijo Ornstein, “nunca se darían
cuenta. Simplemente reiniciarían”.
Pero los chicos de IMP estaban manejando la máquina con fuerza. El flujo de paquetes dentro y fuera del IMP se
produjo más rápido de lo que habían previsto los diseñadores de Honeywell. La máquina 516 no parecía capaz
de manejar semejante tráfico. Quizás BBN había sido demasiado optimista.
Ornstein y Barker fueron a Honeywell e insistieron en que el fabricante “sacara de la nada, en la

trastienda” al diseñador de la computadora 516. Era un tipo muy inteligente, tuvo que admitir Ornstein,
pero al principio el hombre de Honeywell se negó a admitir que fuera posible un estado
metaestable en la máquina. Nunca había leído los artículos de Ornstein y nunca había visto el
problema. “Aunque estaba lleno de incredulidad”, dijo Ornstein, “al menos entendió lo que estábamos
diciendo”.
En condiciones normales, el 516 funcionaría durante años sin experimentar el problema del
sincronizador. Sin embargo, bajo las condiciones de la red de conmutación de paquetes de ARPA, la
máquina fallaba aproximadamente una vez al día. Intente decirle a Frank Heart, Sr. Confiabilidad, que
tendría que vivir con eso.
Ornstein y Barker se acurrucaron. Era sólo una suposición que el IMP tenía un problema de
sincronizador. Para probar la hipótesis, Ornstein diseñó y conectó un "agravador" que
deliberadamente producía solicitudes de datos a lo que Barker llamó un "ritmo feroz". Aumentó la
probabilidad de obtener interrupciones en el nanosegundo exacto que revelaría el problema.
El agravante tenía una perilla que funcionaba como un afinador. Usando la perilla, Ornstein y Barker
podrían "sintonizar" el tiempo de las solicitudes para generar una señal perfectamente desfasada
con el reloj, en el peor de los casos. Luego, utilizando un osciloscopio, observaron los “latidos”
de la máquina y otras funciones internas.
El equipo de depuración se puso a trabajar. Los patrones que buscaban en el osciloscopio

serían tan débiles que sólo serían visibles en una habitación a oscuras. Entonces, con todas las luces
apagadas en la sala IMP y con todo su equipo de diagnóstico y el Honeywell encendido, observaron,
mientras jugaban con el agravante. Las huellas que vieron en el visor eran brillantes, estaban
colocadas regularmente y con un ritmo constante: los signos vitales de una máquina en buen estado.
Incluso con el agravante, al equipo de depuración le llevó bastante tiempo encontrar lo que buscaba.
Aún así, cada pocos minutos un rastro fantasmal muy débil cruzaba el osciloscopio.
¿Fue eso todo? El rastro fugaz fue quizás la única señal reveladora de que los accidentes fueron
causados por un problema de sincronización: un sincronizador se detuvo en una condición
metaestable durante unos pocos nanosegundos de más. Era el equivalente informático de
esa fracción de segundo de confusión o indecisión de un piloto de carreras que termina
repentinamente en un accidente fatal. La evidencia parecía bastante incontrovertible y Honeywell finalmente la reconoció.
Mientras tanto, Barker diseñó una posible solución y recableó la cadena de distribución central del
IMP. Cuando Barker volvió a encender la máquina, cargó su código de diagnóstico y miró por el
visor, los rastros fantasma habían desaparecido.
Si bien Barker y Ornstein estaban razonablemente seguros de que el problema se había solucionado,
no tenían forma de saberlo con seguridad a menos que la máquina funcionara durante unos días
consecutivos sin fallar. Y no tuvieron unos días. Heart ya había aprobado el envío del primer procesador
de mensajes de interfaz a California al día siguiente. El IMP Número Uno casi había salido por la puerta.
5
Hazlo con Truett
Steve Crocker y Vint Cerf habían sido mejores amigos desde que asistieron a la escuela secundaria Van
Nuys en el Valle de San Fernando de Los Ángeles. Compartían el amor por la ciencia y los dos pasaron
más de un par de sábados por la noche construyendo juegos de ajedrez tridimensionales o intentando
recrear los experimentos de Edwin Land con la percepción del color.
Vint era un niño enjuto, intenso y efusivo. Se unió a la unidad ROTC de su escuela secundaria para evitar la
clase de gimnasia. Los días que no se presentaba en la escuela con su uniforme del ROTC, Vint vestía
chaqueta y corbata. Y siempre llevaba consigo un gran maletín marrón. Según los estándares
locales, era una forma de vestir inusual, incluso a finales de la década de 1950. “Usé abrigo y corbata
para distinguirme de la multitud, tal vez la forma de ser diferente de un nerd”, recordó.
Sin embargo, para consternación de sus amigos, Vint nunca tuvo problemas para atraer la atención del
sexo opuesto. Todos estuvieron de acuerdo en que era único en su especie.
Desde temprana edad, Vint aspiró a igualar el exitoso historial de su padre, quien había ascendido de rango
hasta convertirse en un alto ejecutivo en North American Aviation (ahora Rockwell International). Los
dos hermanos menores de Vint jugaban al fútbol y se turnaban como presidente del cuerpo estudiantil. Vint
era el ratón de biblioteca. Sus gustos literarios se inclinaban hacia la fantasía. Ya entrada su vida adulta,
dedicaba regularmente varios días a releer la trilogía de El Señor de los Anillos. A Vint le fue especialmente
bien en química, pero su pasión eran las matemáticas.
Cuando Steve Crocker fundó el club de matemáticas en Van Nuys High, Vint fue uno de los primeros en
unirse.
Como resultado de un parto prematuro, Vint tenía problemas de audición. Aunque posteriormente los
audífonos en ambos oídos corrigieron gran parte del déficit, creció ideando estrategias inteligentes
para comunicarse en el mundo de los oyentes. Años más tarde, después de que se hicieron amigos, Bob
Kahn llamó la atención de sus amigos sobre algunos de los trucos auditivos de Cerf y Cerf finalmente
escribió un artículo llamado "Confesiones de un ingeniero con discapacidad auditiva", en el que compartió
algunos de sus secretos.
En ambientes particularmente ruidosos (cafeterías, restaurantes y hogares con perros y niños

pequeños), la dependencia de la persona sorda del contexto conversacional a menudo se ve gravemente afectada.
Una estrategia típica aquí es dominar la conversación, no hablando solo, sino haciendo muchas preguntas.
De esta manera, el oyente sordo al menos sabrá qué pregunta está dirigiendo el hablante, incluso si no puede
escuchar toda la respuesta. En una conversación grupal, esto puede resultar contraproducente
y vergonzoso si la pregunta que haces es la que acaba de hacer otra persona. Una variación (igualmente
embarazosa) es sugerir con entusiasmo algo que acabamos de sugerir, por ejemplo:
Amigo A: ¿Me pregunto cuál es el origen de este término?
Amigo B: ¿Por qué no lo buscamos en el Oxford English Dictionary?

Amigo A: Sí, pero lástima que no tenemos O.ED.
Cerf: Lo sé. ¿Por qué no lo buscamos en el Oxford English Dictionary?
Steve Crocker entraba y salía de la vida de Vint. Los padres de Steve estaban divorciados y él pasó
sus años de escuela secundaria viajando entre los suburbios de Chicago y el Valle de San Fernando.
Siempre precoz, Steve creció sabiendo que probablemente era el niño más inteligente de cualquier
habitación. A los trece años, mientras estaba en casa un día con un resfriado, aprendió por sí mismo los
elementos de cálculo. Y al final del décimo grado, aprendió los rudimentos de la programación informática.
“Recuerdo que me emocioné cuando finalmente entendí el concepto de bucle”, recordó Crocker, “que
permitía a la computadora realizar una secuencia muy larga de operaciones con sólo unas pocas
instrucciones. Estaba un poco inexperto, pero recuerdo haber pensado que este era el tipo de revelación
que debió haber llevado a Arquímedes a correr desnudo por la calle gritando: '¡Eureka!'”.
Alrededor de 1960, cuando Steve regresó a Los Ángeles, Vint lo siguió al laboratorio de computación de la
UCLA. Aunque todavía estaba en la escuela secundaria, Steve había obtenido permiso para usar la
computadora de UCLA, pero el único tiempo libre que él y Vint tenían eran los fines de semana. Un sábado
llegaron y encontraron el edificio del laboratorio de computación cerrado. "No pude ver otra opción que
rendirme e irme a casa", dijo Crocker. Pero miraron hacia arriba y vieron una ventana abierta en el segundo piso.
Se miraron el uno al otro. “Lo siguiente que supe fue que Vint estaba sobre mis hombros”, recordó
Crocker. Cerf atravesó la ventana y, una vez dentro, abrió la puerta y cerró el pestillo con cinta adhesiva
para poder entrar y salir del edificio. “Cuando los ladrones de Watergate hicieron lo mismo una docena
de años después y fueron atrapados, me estremecí”, dijo Crocker.
Después de la secundaria, Cerf asistió a Stanford con una beca de cuatro años de la empresa de su
padre. Se especializó en matemáticas, pero pronto se enganchó a la informática seria. "Había algo
increíblemente atractivo en la programación", dijo. “Tú creaste tu propio universo y eras su dueño. La
computadora haría cualquier cosa para la que la programaras. Era esta increíble caja de
arena en la que cada grano de arena estaba bajo tu control”.
Después de graduarse en 1965, Cerf decidió que quería trabajar por un tiempo antes de continuar sus
estudios de posgrado. IBM estaba contratando en el campus de Stanford y Cerf aceptó un trabajo en IBM
en Los Ángeles. Empezó a trabajar como ingeniero de sistemas para un sistema de tiempo compartido de IBM.
Al darse cuenta de que necesitaba una mejor base en informática, pronto se unió a su amigo Crocker,
ahora estudiante de posgrado en el departamento de informática de UCLA. La informática era todavía
una disciplina joven y el doctorado de UCLA. El programa, uno de los primeros en el país, era uno de
apenas una docena que existían en ese momento. Cerf llegó justo cuando Crocker partía hacia el MIT.
El asesor de tesis de Crocker en UCLA fue Jerry Estrin, el mismo profesor con el que había
trabajado Paul Baran unos años antes. Estrin tenía un contrato ARPA para la "Computadora Snuper",
que usaba una computadora para observar la ejecución de programas que se ejecutaban en una
segunda máquina. Estrin contrató a Cerf como estudiante de investigación para el proyecto; se convirtió
en la base de la tesis doctoral de Cerf. En el verano de 1968, Crocker regresó a UCLA y se unió a Cerf
en el grupo de Estrin.
Tanto para Cerf como para Crocker, 1968 marcó el comienzo de una fascinación que duraría toda su
vida por las redes de ordenadores. Para Cerf, las redes informáticas se convertirían en la pieza central
de su carrera profesional. Aunque Crocker pasaría a otras cosas durante largos períodos,
eventualmente también regresaría al campo de las redes.
En el otoño de 1968, ARPA transfirió su contrato de Estrin a Len Kleinrock en UCLA.

Kleinrock estaba montando su Centro de Medición de Redes, con un contrato anual de 200.000
dólares de ARPA. Por coincidencia, cuando Kleinrock obtuvo el contrato, la persona de la oficina de al
lado se mudó convenientemente, por lo que Kleinrock amplió su dominio; derribó la pared entre las
dos oficinas e instaló una gran mesa de conferencias para reuniones con estudiantes y personal. Las
reuniones eran frecuentes mientras Kleinrock construía afanosamente un pequeño imperio.
Al planificar la red ARPA, Larry Roberts había concebido el Centro de medición de redes
como la organización responsable de la mayor parte de las pruebas y análisis de rendimiento. El
centro de medición pretendía ser más o menos análogo a una pista de pruebas donde los conductores
superan los límites de los coches de alto rendimiento.
Kleinrock y su grupo estaban a cargo de recopilar datos (tiempo total de respuesta de la red, densidad
de tráfico, retrasos y capacidad), las medidas necesarias para evaluar el rendimiento de la red. Al igual
que Bob Kahn, Kleinrock tenía inclinaciones teóricas; su negocio era la simulación, el modelado y
el análisis. A través de simulaciones, había llegado lo más cerca que pudo de monitorear la forma en
que funcionan las redes sin tener realmente una red que ejecutar. Agradeció la oportunidad de
probar sus teorías en la realidad.
Los ingenieros de BBN no le prestaron demasiada atención a Kleinrock. Pensaban que era un poco pesado
en teoría y bastante ligero en ingeniería. El escepticismo era mutuo, ya que Kleinrock creía que el
equipo de BBN no estaba en gran medida interesado en el rendimiento. Los programadores de BBN
fueron sobresalientes, pero, dijo Kleinrock, “en general, un programador simplemente quiere obtener un
software que funcione. Eso ya es bastante difícil. Por lo general, el problema no es si funciona
bien o eficientemente”. Quizás no era consciente de la obsesión de Walden y Crowther por la
eficiencia del software, pero en cualquier caso, Kleinrock decidió que
perfeccionar el rendimiento de la red era su trabajo.
Al poco tiempo, Kleinrock estaba dirigiendo a cuarenta estudiantes que ayudaban a administrar el centro.
Crocker y Cerf se encontraban entre los miembros más antiguos del grupo de Kleinrock. Otro
miembro importante fue Jon Postel. Tenía una barba larga y espesa, usaba sandalias todo el año y
nunca se había puesto corbata en su vida. Siempre elegante y generalmente más conservador,
Cerf presentaba un sorprendente contraste con la apariencia firmemente informal de Postel.
Crocker, el líder no oficial, estaba en algún punto intermedio. Se había dejado barba en el MIT (“Los
policías me miraban un poco más fijamente, pero las chicas eran mucho más amigables, y eso era un
compromiso con el que podía vivir”, dijo Crocker), pero estaba dispuesto a ponerse un par de zapatos
de vestir de vez en cuando.
Mientras Cerf y Crocker eran estrellas académicas, Postel, que tenía veinticinco años, había tenido
una carrera académica más accidentada. Se había criado en las cercanas Glendale y Sherman
Oaks, y también había asistido a la escuela secundaria Van Nuys, donde sus notas eran mediocres.
El interés de Postel por las computadoras se desarrolló en un colegio comunitario local. Para cuando llegó
a UCLA para terminar una licenciatura en ingeniería (lo más parecido a la informática en ese momento) la
informática era su vida. La UCLA finalmente decidió establecer ciencias de la computación como
un departamento formal, justo en el momento en que Postel ingresaba a la escuela de posgrado de la
universidad. Postel estaba callado, pero tenía opiniones firmes. Los responsables del departamento
de informática interpretaron en ocasiones la firmeza de las opiniones de Postel como una mala
actitud.
En 1966 Cerf se había casado con una joven ilustradora llamada Sigrid. Estaba profundamente sorda.
Su primera reunión había sido ideada por su distribuidor de audífonos, quien les programó citas
adyacentes un sábado por la mañana con la esperanza de que se cruzaran y se llevaran bien. Fueron
a almorzar y Sigrid quedó asombrada por la curiosidad ecléctica de su acompañante. Vint parecía
bailar en su silla de emoción mientras describía su trabajo con las computadoras. Ampliaron su têteà
tête con una visita al Museo de Arte del Condado de Los Ángeles para ver algunas de las pinturas
favoritas de Sigrid. Sin estudios de arte pero deseoso de aprender, Cerf contempló durante mucho tiempo
un enorme Kandinsky. “Esto me recuerda a una hamburguesa verde”, comentó finalmente. Un año
después se casaron, con Steve Crocker como padrino de boda de Vint (roles que se invertirían unos
años más tarde). La experiencia de Crocker en electrónica resultó útil cuando, minutos antes de que
comenzara la ceremonia, descubrió que la grabadora de la música de la boda no funcionaba correctamente.
El padrino y el frenético novio se retiraron a una pequeña habitación cerca del altar y la arreglaron justo
a tiempo.
Kleinrock, aunque sólo diez años mayor que el resto de su grupo, tenía una gran reputación en la teoría
de las colas (el estudio de cuánto tiempo pasan las personas y las cosas esperando en las colas, cuánto
se alargan las colas y cómo diseñar sistemas para reducir las esperas). . Ya había publicado un
libro y estaba a cargo de un laboratorio en crecimiento; su energía parecía ilimitada.
Además, era uno de los pocos científicos que habían producido modelos analíticos de redes de
almacenamiento y reenvío antes de que Roberts comenzara el proyecto ARPA.
En ese momento, el departamento de informática de UCLA poseía una computadora fabricada

por Scientific Data Systems llamada Sigma7, la última de la línea de computadoras de esa empresa.
UCLA también tenía tres importantes centros informáticos equipados con mainframes IBM 7094. Pero la
Sigma7 fue la máquina asignada a los estudiantes de posgrado. A nadie le gustó mucho el Sigma7. Era
poco fiable y difícil de programar. Como dijo un miembro del equipo de UCLA, el Sigma7 era un perro.
(“Pero era nuestro perro”, dijo Cerf años después). También era la única computadora con la que tenían
para jugar, hasta que apareció la red ARPA. No sólo los científicos informáticos de UCLA recibirían el
primer IMP, sino que presumiblemente la red abriría puertas a todo tipo de máquinas host diferentes en
los otros sitios.
La tarea más urgente en el verano de 1969 fue construir la interfaz (una combinación de hardware y
software) entre el Sigma7 y el IMP. Según lo entendieron los chicos de UCLA, BBN estaba
elaborando algunas especificaciones sobre cómo construir dicha conexión. La interfaz de host a IMP
tuvo que construirse desde cero cada vez que se establecía un nuevo sitio en torno a un modelo de
computadora diferente. Más tarde, los sitios que utilizaran el mismo modelo podrían comprar copias
de la interfaz personalizada.
Casi igual de urgente era el desafío de mayor alcance: escribir el software que permitiera a las computadoras
host de toda la red comunicarse entre sí. esto iba a ser
el protocolo de host a host, un conjunto muy amplio de términos operativos que serían comunes a
todas las máquinas. Tenía que ser como un cheque de viajero: válido en cualquier lugar y capaz de admitir una
gama de aplicaciones, desde inicios de sesión remotos hasta transferencias de archivos y procesamiento de texto.
Inventarlo no sería fácil.
La búsqueda de protocolos
En el verano de 1968, un pequeño grupo de estudiantes graduados de los primeros cuatro sitios anfitriones:
UCLA, SRI, UC Santa Bárbara y la Universidad de Utah se habían reunido en Santa Bárbara.
Sabían que se estaba planeando la red, pero les habían dado pocos detalles más allá de eso. Pero el networking
en general, y el experimento ARPA en particular, fueron temas candentes.
La reunión fue fundamental, aunque sólo fuera por el entusiasmo que generó. "Teníamos muchas preguntas:
cómo se conectarían los IMP y los hosts, qué se dirían los hosts entre sí y qué aplicaciones serían compatibles",
dijo Crocker. “Nadie tenía respuestas, pero las perspectivas parecían apasionantes. Nos encontramos
imaginando todo tipo de posibilidades.
gráficos interactivos, procesos cooperativos, consulta automática de bases de datos, correo electrónico—
pero nadie sabía por dónde empezar”.
De esa reunión surgió un cuerpo de jóvenes investigadores dedicados a trabajar, pensar e idear sobre las
comunicaciones de host a host de la red. Para acelerar el proceso, decidieron reunirse periódicamente. En
teoría, una red informática reduciría algunos de los viajes financiados por ARPA, pero en poco tiempo Crocker
estaba viajando lo suficiente como para que Kleinrock tuviera que conseguirle un presupuesto de viaje separado.
Aproximadamente un mes después de que el nuevo grupo comenzara a reunirse, Crocker y otros tuvieron claro
que sería mejor que comenzaran a acumular notas sobre las discusiones. Si las reuniones en sí no
fueran concluyentes, tal vez el acto de escribir algo ayudaría a ordenar sus pensamientos. Crocker se ofreció a
escribir los primeros minutos. Era un joven sumamente considerado, sensible hacia los demás. "Recuerdo
haber tenido un gran temor de ofender a quienes fueran los diseñadores oficiales del protocolo". Por supuesto,
no hubo diseñadores de protocolos oficiales, pero Crocker no lo sabía. En ese momento vivía con amigos y
trabajó toda la noche en la primera nota, escribiendo en el baño para no despertar a nadie en la casa. No
estaba tan preocupado por lo que quería decir sino que quería lograr el tono correcto. "Las reglas básicas eran
que cualquiera podía decir cualquier cosa y que nada era oficial".
Para evitar parecer demasiado declarativo, etiquetó la nota como "Solicitud de comentarios" y la envió el 7 de
abril de 1969. Titulada "Software host", la nota se distribuyó a los otros sitios de la misma manera que todas las
primeras Solicitudes de comentarios (RFC). fueron distribuidos: en un sobre con la lamida de un sello. El RFC
número 1 describía en términos técnicos el “apretón de manos” básico entre dos computadoras: cómo se
manejarían las conexiones más elementales.
Resultó que “Solicitud de comentarios” era una elección perfecta de títulos. Sonó a la vez solícito y serio. Y se
quedó.
“Cuando leías RFC 1, te alejabas de él con la sensación de: 'Oh, este es un club en el que yo también puedo
tocar'”, recordó Brian Reid, más tarde estudiante de posgrado en CarnegieMellon. "Él
tiene reglas, pero da la bienvenida a otros miembros siempre que los miembros conozcan esas
reglas”. El lenguaje del RFC fue cálido y acogedor. La idea era promover la cooperación, no el ego. El
hecho de que Crocker mantuviera su ego fuera del primer RFC marcó el estilo e inspiró a otros a seguir su
ejemplo en los cientos de RFC amistosos y cooperativos que siguieron. "Es imposible subestimar la
importancia de esto", afirmó Reid. “No me sentí excluido por un pequeño núcleo de reyes del protocolo. Me
sentí incluido por un grupo amigable de personas que reconocieron que el propósito de la creación de
redes era atraer a todos”. Durante años (y hasta el día de hoy), los RFC han sido el principal medio de
expresión abierta en la comunidad de redes informáticas, la forma aceptada de recomendar, revisar y
adoptar nuevos estándares técnicos.
Al poco tiempo, la asamblea comenzó a llamarse Grupo de Trabajo de Red, o NWG.

Fue un alto encargo para los jóvenes y excepcionalmente talentosos programadores de
comunicación del país. Su principal desafío fue llegar a un acuerdo de principio sobre los
protocolos: cómo compartir recursos, cómo transferir datos, cómo hacer las cosas. En términos reales,
eso significaba escribir programas, o al menos adoptar ciertas reglas para la forma en que se
escribían los programas, reglas a las que una mayoría podía dar su consentimiento. El acuerdo era la
condición sine qua non. Se trataba de una comunidad de iguales. Todos podían escribir código o reescribir
el código que alguien más había escrito. El NWG era una adhocracia de genios informáticos
intensamente creativos, privados de sueño, idiosincrásicos y bien intencionados. Y siempre casi esperaban,
cualquier día, ser cortésmente agradecidos por su trabajo y rápidamente reemplazados por otros a
quienes imaginaban que eran los verdaderos profesionales del campo. No había nadie que les dijera que
eran tan oficiales como parecía. El RFC, un mecanismo sencillo para distribuir documentación abierto a
cualquiera, tuvo lo que Crocker describió como un “efecto de primer orden” en la velocidad a la que se
difundían las ideas y en la difusión de la cultura de las redes.
Anticipándose a la construcción de la red, el Grupo de Trabajo de la Red continuó reuniéndose

periódicamente y, a menudo, surgieron por consenso nuevos términos e invenciones. La propia palabra
"protocolo" llegó al lenguaje de las redes informáticas basándose en la necesidad de un acuerdo
colectivo entre los usuarios de la red. Durante mucho tiempo la palabra se ha utilizado para la etiqueta
de la diplomacia y para ciertos acuerdos diplomáticos. Pero en griego antiguo, protokollon significaba la
primera hoja de un volumen, una guarda adherida a la parte superior de un rollo de papiro que
contenía una sinopsis del manuscrito, su autenticación y la fecha.
De hecho, la palabra que se refiere a la parte superior de un pergamino correspondía bien al encabezado
de un paquete, la parte del paquete que contiene información de dirección. Pero un significado menos
formal parecía aún más apropiado. "La otra definición de protocolo es que es un acuerdo escrito a mano
entre las partes, generalmente elaborado en la parte posterior de una bolsa de almuerzo", comentó Cerf,
"que describe con bastante precisión cómo se hicieron la mayoría de los diseños del protocolo".
Pero las primeras reuniones del Grupo de Trabajo de la Red fueron poco productivas.
Durante el transcurso de la primavera y el verano de 1969, el grupo continuó luchando con los problemas
del diseño del protocolo anfitrión. Todos tenían una visión del potencial de la comunicación entre
computadoras, pero nadie se había sentado nunca a construir protocolos que realmente pudieran usarse.
No era trabajo de BBN preocuparse por ese problema. La única promesa que alguien de BBN había
hecho sobre la subred planificada de IMP era que movería los paquetes de un lado a otro y se aseguraría
de que llegaran a su destino. Depende totalmente de la computadora host descubrir cómo comunicarse
con otro host.
computadora o qué hacer con los mensajes una vez que los recibió. Esto se denominó protocolo
“host a host”.
Las computadoras mismas eran dispositivos extremadamente egocéntricos. La computadora central

típica de la época se comportaba como si fuera la única computadora del universo. No había una
manera obvia o fácil de conectar dos máquinas diversas ni siquiera en la comunicación mínima
necesaria para mover bits de un lado a otro. Se podrían conectar máquinas, pero una vez
conectadas, ¿qué se dirían entre sí? En aquellos días una computadora interactuaba con los
dispositivos que tenía conectados, como un monarca comunicándose con sus súbditos.
Todo lo conectado a la computadora principal realizaba una tarea específica, y se suponía que
cada dispositivo periférico estaba listo en todo momento para una orden del tipo "busca mis
zapatillas". (En el lenguaje informático, esta relación se conoce como comunicación maestroesclavo).
Las computadoras fueron diseñadas estrictamente para este tipo de interacción; envían
instrucciones a lectores de tarjetas, terminales y unidades de cinta subordinados e inician todos los
diálogos. Pero si, de hecho, otro dispositivo golpeara el hombro de la computadora con una señal que
dijera: "Hola, yo también soy una computadora", la máquina receptora quedaría perpleja. El objetivo
al diseñar el protocolo de host a host era lograr que las máquinas mainframe hablaran como pares,
de modo que cualquiera de las partes pudiera iniciar un diálogo simple y la otra estuviera lista para
responder con al menos un reconocimiento de la existencia de la otra máquina.
Steve Crocker comparó una vez el concepto de protocolo de host a host con la invención de los dos
por cuatro. “Te imaginas ciudades, edificios, casas, etc., pero lo único que ves son árboles y bosques.
Y en algún momento del camino, descubres dos por cuatro como bloque de construcción
intermedio, y dices, bueno, puedo sacar dos por cuatro de todos estos árboles”, recordó Crocker.
"No teníamos el concepto de un equivalente de dos por cuatro, los protocolos básicos para hacer
que todas las computadoras hablen y que serían útiles para construir todas las aplicaciones". El
equivalente informático de un dos por cuatro era lo que el Grupo de Trabajo en Red estaba
intentando inventar.
Al concebir el protocolo, los miembros del NWG tuvieron que plantearse algunas preguntas
básicas. ¿Qué forma debería adoptar la base común? ¿Debería haber un protocolo único
y fundamental sobre el cual construir todos los protocolos de aplicación? ¿O debería ser más
complejo, subdividido, estratificado y ramificado? Cualquiera que fuera la estructura que eligieran,
sabían que querían que fuera lo más abierta, adaptable y accesible a la inventiva posible. La
opinión general era que cualquier protocolo era un componente potencial, por lo que el mejor
enfoque era definir protocolos simples, cada uno de ellos de alcance limitado, con la expectativa de
que algún día cualquiera de ellos pudiera unirse o modificarse de diversas maneras imprevistas.
La filosofía de diseño de protocolos adoptada por el NWG abrió el camino para lo que llegó a
ser ampliamente aceptado como el enfoque “en capas” de los protocolos.
Uno de los objetivos más importantes al crear el protocolo de capa inferior entre hosts era poder
mover un flujo de paquetes de una computadora a otra sin tener que preocuparse por lo que había
dentro de los paquetes. El trabajo de la capa inferior era simplemente mover bits genéricos no
identificados, independientemente de lo que los bits pudieran definir: un archivo, una sesión
interactiva entre personas en dos terminales, una imagen gráfica o cualquier otra forma concebible
de datos digitales. De manera análoga, una parte del agua del grifo se utiliza para preparar café,
otra para lavar los platos y otra para bañarse, pero a la tubería y al grifo no les importa; ellos
transportar el agua independientemente. El protocolo de host a host debía realizar esencialmente la misma
función en la infraestructura de la red.
Diseñar el protocolo de host a host no era el único trabajo que tenía por delante el grupo. El NWG también tuvo
que escribir aplicaciones de red para tareas específicas como la transferencia de archivos. A medida que las
conversaciones se centraron más, se decidió que las dos primeras aplicaciones deberían ser para inicios
de sesión remotos y transferencias de archivos.
En la primavera de 1969, unos meses antes de que Kleinrock y el equipo anfitrión de la UCLA esperaran
recibir el primer IMP, llegó un sobre grueso de Cambridge. Los chicos de UCLA lo estaban anticipando. Dentro
del paquete estaba el Informe BBN 1822, el conjunto de especificaciones recientemente escrito para conectar
computadoras host a los IMP que se entregarán próximamente. La red ARPA finalmente parecía estar
funcionando.
Después de meses de conjeturas, el equipo de UCLA aprendió lo que se esperaba que hiciera para preparar su
sitio y construir su interfaz de hardware. El Informe BBN 1822 también instruyó a los sitios a crear una pieza de
software llamada controlador de dispositivo (una colección de códigos y tablas para controlar un dispositivo
periférico) para operar la interfaz de host a IMP. Y, finalmente, la emisión de las especificaciones por parte
de BBN aclaró el límite entre el IMP y el host.
Estaba claro que BBN no planeaba incluir ningún software especial en el IMP para realizar la comunicación de
host a host. Ese problema quedaría, de una vez por todas, en manos del ordenador anfitrión y, por tanto, del
NWG.
Esto significó mucho trabajo de verano para los estudiantes de Los Ángeles. Pensaron que podrían terminar de
construir la interfaz de host a IMP a tiempo. Pero escribir el protocolo de host a host ya había paralizado a
Crocker, Cerf y a todo el Grupo de Trabajo de la Red durante meses. En lugar de intentar apresurar algo a
tiempo, decidieron decirle a cada sitio que elaborara sus propios protocolos improvisados por el momento.
UCLA pidió a los técnicos de Scientific Data Systems, creadores del Sigma7, que construyeran el hardware de
interfaz para su conexión de host a IMP. La respuesta de la empresa fue desalentadora: llevaría meses y
probablemente no estaría terminado a tiempo para la llegada del IMP. Además, la empresa quería decenas
de miles de dólares por el trabajo. Entonces, cuando un estudiante de posgrado llamado Mike Wingfield pidió el
trabajo, lo consiguió. ¿Y por qué no? Wingfield era un genio del hardware y acababa de terminar de construir
una interfaz gráfica compleja para otra computadora.
La especificación de BBN para las interacciones y conexiones de host a IMP fue un modelo espléndido. Una
especie de libro de cocina, escrito por Bob Kahn en prosa cristalina, el documento iba acompañado de
diagramas detallados. La especificación de Kahn le dio a Wingfield los requisitos básicos para acoplar el
Sigma7 a un IMP. Casi antes de que Wingfield se diera cuenta, el verano había pasado volando y la interfaz
se había construido sin problemas.
Una semana antes de la llegada prevista del IMP el 1 de septiembre, Wingfield tenía el hardware terminado,
depurado y listo para conectarse al IMP. Crocker quedó tan impresionado que lo describió como un trabajo
"hermoso". Pero al intentar terminar el software de comunicaciones, Crocker se estaba quedando atrás. De
todos modos, tenía tendencia a posponer las cosas, y la ausencia del IMP real sólo había fomentado esta
tendencia.
Ahora, como cualquiera que intenta burlar una fecha límite, Crocker miró el calendario e hizo algunos
cálculos. Contaba con tener al menos un día extra, ya que el 1 de septiembre era el Día del Trabajo.
Además, había oído que BBN estaba teniendo algunos problemas con la cadena de distribución del
IMP. Los errores del sincronizador eran terriblemente desagradables. Su problema era su buena suerte y,
con un poco de suerte, incluso podría conseguirle una o dos semanas más, pensó. Así que quedó más que
ligeramente sorprendido cuando Len Kleinrock le dijo que BBN estaba a punto de poner el IMP en un
avión que debía llegar a Los Ángeles el sábado 30 de agosto, dos días antes.
En Cambridge, Frank Heart estaba preocupado por la mejor manera de enviar el IMP a UCLA.
Después de debatir durante un par de días, Heart decretó que debería ir por aire y que Ben Barker debería
ir con él. Un vuelo comercial estaba fuera de discusión. El Honeywell 516 modificado, ahora oficialmente
procesador de mensajes de interfaz BBN número uno, era demasiado grande para el compartimento
de carga de un avión de pasajeros. Tenía que salir por transporte aéreo. Si Heart hubiera podido,
habría puesto a Barker directamente en la bodega del avión de carga con la muñeca esposada al IMP.
No importaba que hubiera elegido la máquina precisamente porque estaba endurecida por la batalla;
Los rigores del combate no eran nada comparados con el castigo que podían imponer los transportistas
de carga aérea. "Quería que hubiera alguien allí, gritando a la gente de carga para asegurarse de que no
fueran descuidados", recordó Barker.
Pero Barker tendría que viajar por separado en un vuelo comercial de pasajeros. A Truett Thach,
técnico de la oficina de BBN en Los Ángeles, se le pediría que esperara el avión.
Una vez que el IMP estuvo embalado, Barker tomó un marcador mágico rojo y en letras grandes escribió
HAZLO VERDADERO en el costado de la caja. Lo cargaron en un vuelo temprano en la mañana que salía
del aeropuerto Logan de Boston, y Thach estaba allí para recibirlo en LAX esa tarde. Cuando llegó,
acompañado por un transportista de carga, se sintió aliviado al ver la caja salir del avión, pero se horrorizó
cuando notó que el mensaje de Barker estaba al revés.
"En algún momento del camino, el IMP se había invertido un número impar de veces", observó.
Thach hizo que los transportistas enderezaran la caja antes de cargarla en su camión. Luego los siguió
hasta la UCLA.
Era el sábado anterior al Día del Trabajo y Thach notó que las calles estaban inusualmente tranquilas a lo
largo de Westwood y hasta el campus. Barker ya estaba esperando en el muelle de carga de Boelter
Hall con una docena de personas más: Kleinrock, Crocker, Postel, Wingfield, Vint y Sigrid Cerf, y
un puñado de curiosos. Los Cerf habían traído champán. Inmediatamente después de ver la caja, alguien
preguntó si cabría en el ascensor; El IMP fue desembalado para poder encajarlo.
Cuando sacaron la máquina de la caja, los asistentes de bienvenida quedaron sorprendidos por su tamaño.
Aunque más pequeño que el Sigma7, no era un dispositivo pequeño. Era aproximadamente del tamaño
de un refrigerador, pesaba más de cuatrocientas libras y estaba formidablemente recubierto de acero gris
acorazado, exactamente según las especificaciones militares. Encima del IMP había cuatro cáncamos de
acero para subirlo a un barco mediante una grúa o un helicóptero. En UCLA, el IMP era como un soldado
con uniforme de combate que irrumpe en una fiesta de profesores.
Cuando el ascensor llegó al tercer piso, los transportistas llevaron la máquina por el pasillo y doblaron la
esquina hasta su nuevo hogar en la habitación 3400. El Sigma7 zumbaba cerca, ajeno a la perturbación
masiva que estaba a punto de invadir su privacidad. "Era un poco como ver a tus padres invitar a cenar a
alguien que nunca habías conocido", dijo Crocker.
"No prestas mucha atención hasta que descubres que en realidad tienen la intención de casarte con este
extraño".
Thach y Barker pasaron unos minutos cableando el IMP y encendiéndolo. Al instante, la memoria central
de la máquina supo exactamente qué hacer: continuó justo donde lo había dejado en Cambridge,
ejecutando los diagnósticos que los chicos del IMP habían escrito para ella. A continuación, Mike
Wingfield adjuntó su interfaz. Dado que este era el nodo número uno, no había una red por
temporada para probarlo. Pero Barker podía hacer experimentos de derivación entre el Sigma7 y el IMP
como lo había hecho muchas veces en Moulton Street entre máquinas para simular enlaces de red. Al cabo
de una hora, el Sigma7 y el IMP estaban pasando datos de un lado a otro como si lo hubieran estado
haciendo durante años.
Barker todavía no estaba absolutamente seguro de que el problema del sincronizador se hubiera resuelto.
Pero tenía la suficiente confianza como para considerar volver a casa. Esa noche, Barker llamó a Heart.
"Hemos terminado, todo está funcionando", dijo. “Se trata de hablar con el material de Mike [Wingfield].
Estoy pensando en coger un vuelo a casa por la mañana.
Heart hizo una pausa y Barker intuyó lo que podría estar por venir. "¿Por qué no te quedas ahí unos
días?" Corazón respondió. "Sólo para ver si algo sale mal". Barker pasó tres días relajándose con Thach,
recorriendo Los Ángeles y esperando que el IMP se estrellara. No fue así.
Una verdadera red

Un mes después de que se instalara el primer IMP en UCLA, el IMP número dos llegó al SRI, justo a
tiempo, el 1 de octubre de 1969. Ese mismo mes, Bob Taylor dejó ARPA. Hacía tiempo que se había
alejado de los detalles del proyecto de la red. Según explicó, en la década de 1960, “ARPA” era una palabra
mágica. A menudo se recurría a la oficina de Taylor para resolver problemas que otros no podían. En 1967
y 1968, Taylor había sido enviado repetidamente a Vietnam para ayudar a aclarar, entre otras cosas,
la controversia sobre los informes de “recuento de cadáveres” del ejército manejados por los centros
de información militar. La experiencia había dejado a Taylor agotado. Aceptó un puesto en la Universidad de
Utah.
Hasta el momento se habían superado muchos hitos en el experimento de la red: la victoria financiera
de Taylor y el exitoso cortejo de Roberts; El concepto de red de Roberts; Construcción y
entrega del primer IMP por parte de BBN. Pero la instalación del IMP Número Dos marcó el logro más
importante hasta la fecha. Por fin los investigadores pudieron conectar dos ordenadores distintos y hacer que
hablaran entre sí como un par de viejos camaradas.
Al igual que antes el equipo de UCLA, el grupo de SRI tuvo una lucha loca similar preparándose para la
llegada del IMP. Una diferencia crucial entre los dos sitios fue que mientras a los chicos de UCLA no les
gustaba su Sigma7, a los chicos de SRI les encantaba su computadora host, una SDS 940.
Al igual que el Sigma7, el 940 fue construido por Scientific Data Systems. Pero el Sigma7 tenía
Fue diseñado como un procesador comercial, mientras que el 940 era básicamente un dispositivo
académico, un revolucionario sistema de tiempo compartido creado por primera vez por un equipo de
investigadores de Berkeley, que luego se vendería bajo la denominación SDS. Como resultado, era mucho
más divertido de programar que el Sigma7.
Bill Duvall, un investigador del SRI, pasó aproximadamente un mes escribiendo un programa inteligente para
el 940 que esencialmente lo engañó haciéndole creer que no se estaba comunicando con otra computadora
sino con una terminal “tonta”. Un terminal tonto no puede ni calcular ni almacenar información; sólo sirve para
mostrar el conjunto de información más reciente que le envió la computadora a la que está vinculado. El
programa de Duvall fue una solución provisional muy específica al problema de comunicación entre hosts.
Durante semanas, los investigadores de UCLA se habían estado preparando para su primera sesión de inicio
de sesión marcando a larga distancia el sistema SRI utilizando un módem y un teletipo, para familiarizarse
con el sistema de tiempo compartido del SRI. Con ambos IMP ya instalados y ambos hosts en
funcionamiento, finalmente había llegado el momento de probar la red ARPA de dos nodos real.
Lo primero que había que hacer, por supuesto, era conectarse. A diferencia de la mayoría de los
sistemas actuales, que solicitan al usuario un nombre de inicio de sesión y una contraseña, el sistema SRI
esperaba un comando antes de reconocer una conexión. “INICIAR SESIÓN” fue uno de esos comandos.
Sujeta a los primeros IMP como si fuera un percebe había una pequeña caja parecida a un teléfono, con
un cable y unos auriculares. Compartió la línea con los IMP y utilizó un subcanal destinado a
conversaciones de voz. La línea de voz era, al igual que la línea de datos, un enlace exclusivo. Unos días
después de que el IMP estuviera instalado en SRI, Charley Kline, entonces estudiante universitario en UCLA,
tomó el auricular del teléfono en Los Ángeles y presionó un botón que hizo sonar una campana en el IMP
en Menlo Park. Un investigador del grupo de Engelbart en el SRI respondió. De algún modo, para
Kline era más emocionante que marcar un teléfono normal.
La calidad de la conexión no era muy buena y ambos hombres estaban sentados en salas de
ordenadores ruidosas, lo que no ayudó. Entonces Kline gritó por el micrófono: “¡Voy a escribir anL!”.
Kline escribió anL.
“¿Recibiste la L?” preguntó. “Obtuve uno uno cuatro”, respondió el investigador del SRI; estaba leyendo la
información codificada en octal, un código que utiliza números expresados en base 8.
Cuando Kline hizo la conversión, vio que en realidad era una L que había sido transmitida. Escribió una O.
“¿Recibiste la O?” preguntó.
“Obtuve uno uno siete”, fue la respuesta. Era una O.
Kline escribió aG.
"La computadora simplemente falló", dijo la persona del SRI. El fracaso se produjo gracias a una programación
inteligente por parte de Duvall. Una vez que la máquina SRI reconoció las letras LOG, completó la palabra.
"Creo que ahí es donde estaba el error", recordó Kline. "Cuando el sistema SRI 940 recibió la G, intentó
devolver "GIN" y el programa del terminal no estaba listo para manejar más de un carácter a la vez".
Más tarde ese mismo día lo intentaron de nuevo. Esta vez funcionó perfectamente. Crocker, Cerf y Postel
fueron a la oficina de Kleinrock para contárselo para que pudiera verlo por sí mismo. De vuelta en el
laboratorio de UCLA, Kline se conectó a la máquina SRI y pudo ejecutar comandos en el sistema de tiempo
compartido del 940. La computadora SRI en Menlo Park respondió como si el Sigma7 en Los
Ángeles fuera una auténtica y tonta terminal.
No es poca ironía el hecho de que el primer programa utilizado en la red fuera uno que hacía que la
computadora distante se hiciera pasar por una terminal. Todo ese trabajo para que dos
computadoras se comunicaran entre sí y terminaron en la misma situación maestroesclavo que se suponía
que la red eliminaría. Por otra parte, los avances tecnológicos a menudo comienzan con intentos de
hacer algo familiar. Los investigadores generan confianza en las nuevas tecnologías al demostrar que
podemos usarlas para hacer cosas que entendemos. Una vez que lo han hecho, los siguientes pasos
comienzan a desarrollarse, a medida que la gente comienza a pensar aún más en el futuro. A
medida que las personas asimilan el cambio, la próxima generación de ideas ya está evolucionando.
Ahora existía una red. El primer mapa de la red ARPA tenía este aspecto:
El IMP Número Tres se instaló en UC Santa Bárbara el 1 de noviembre. Para la instalación en Santa
Bárbara, Barker voló nuevamente a California. En ese momento, Heart estaba más relajado. Había
pocos rastros del suspenso que había acompañado al primer viaje. De hecho, la instalación de IMP
empezaba a parecer una rutina.
Ese mismo mes, Larry Roberts decidió volar a California para inspeccionar la red de primera mano
por primera vez. A Roberts no le gustaba viajar. Cuando viajaba, nunca salía a coger el avión hasta el
último minuto. Esto volvió loca a su secretaria, pero sólo perdió un avión que nadie pudiera recordar.
Eso sucedió una tarde cuando lo detuvieron por exceso de velocidad en su camino al aeropuerto
de Dulles. Convencido de que no había ido demasiado rápido, Roberts decidió impugnar la multa. El
coche patrulla lo había detenido cerca del punto en el que había llegado a George Washington Parkway
después de una parada total, y su argumento era que en esa corta distancia no podría haber acelerado
su Volkswagen Beetle a la velocidad alegada por el oficial. Roberts regresó al lugar y midió
cuidadosamente las distancias. Reunió datos sobre la potencia del motor y el peso de su VW, tuvo en
cuenta la ley de inercia de Newton e hizo algunos
otros cálculos, y estaba dispuesto a presentarse ante un juez para presentar su caso. No fue hasta que
sus amigos lo convencieron de que era poco probable que consiguiera un juez con un título en
física que aceptó el punto y pagó la multa en lugar de llevarlo a los tribunales.
Afortunadamente, no hubo multas por exceso de velocidad en este viaje. Roberts y su director de
programa, Barry Wessler, volaron a California sin incidentes y en el laboratorio de Kleinrock en Boelter
Hall observaron la red en funcionamiento. Esta vez, Kleinrock escribió y en menos de un minuto
había iniciado sesión en la computadora central del SRI. Roberts observó atentamente y salió satisfecho
de que el experimento estaba teniendo éxito.
El cuarto lugar fue Utah. Ya era diciembre, la mejor temporada de esquí. También había programada una
reunión del Grupo de Trabajo de la Red en el sitio. Todos los esquiadores entusiastas, todo el equipo
BBN, incluso Frank Heart, fueron a Salt Lake City para conectar el IMP. (Irónicamente, Barker fue el
único excluido del viaje a Utah, un hecho que no dejó que los demás olvidaran durante muchos años).
La disposición del creciente número de enlaces de comunicación se estaba convirtiendo en un problema

interesante. Por un lado, no había un vínculo punto a punto entre cada par de sitios.
Por razones de economía, Roberts decidió que no era necesario un enlace directo entre UCLA y Utah,
o entre Santa Bárbara y Utah, por lo que todo el tráfico con destino a Utah tenía que pasar por el IMP
en el SRI. Eso estaba bien mientras estuviera en funcionamiento. Si colapsara, la red se dividiría y
Utah quedaría aislada hasta que el SRI volviera a estar en línea.
Al final resultó que, la red de cuatro nodos que diseñó Roberts no era una red sólida de conexiones
redundantes.
Las perturbaciones en el sistema también se manifestaron de maneras menos obvias. Esto quedó
claro muy pronto, cuando los estudiantes de Santa Bárbara comenzaron a hacer exactamente lo
que Heart temía que hicieran: jugar con su nuevo juguete. Y su actitud fue: ¿Por qué no?
Nunca habían tenido que preocuparse por las conexiones externas y no se les ocurrió que algo que
hicieran en su laboratorio de computación pudiera tener un efecto en otros lugares. “Pensamos
alegremente que podíamos jugar con el IMP”, recordó Roland Bryan, un investigador de Santa
Bárbara. "Lo probamos, lo encendimos y apagamos, lo reiniciamos, lo recargamos y lo intentamos
de nuevo". Como resultado, las personas que estaban tomando mediciones de la red y que
contaban con la ruta de la red a través de Santa Bárbara verían desechado su experimento. "Aunque no
dañamos los vínculos entre otros sitios, estábamos interrumpiendo el análisis del tráfico de datos que
realizaban BBN y UCLA", dijo Bryan. "No pensamos en el hecho de que cada vez que hiciéramos eso,
alguien sufriría".
A finales de 1969, el Grupo de Trabajo de Redes todavía no había ideado un protocolo de host a host.
Bajo presión para mostrarle algo a ARPA en una reunión con Roberts en diciembre, el grupo
presentó un protocolo integrado (Telnet) que permitía inicios de sesión remotos. Roberts no estaba
satisfecho con el alcance limitado del esfuerzo. Aunque Telnet era claramente útil y fundamental
porque permitía que una terminal llegara a múltiples computadoras remotas, un programa de
inicio de sesión remoto por sí solo no resolvía el problema de permitir que dos computadoras
trabajaran juntas. Además, Telnet era una forma de utilizar la red, no un elemento básico de nivel
inferior. Roberts los envió de regreso para seguir intentándolo. Después de otro año de reuniones y
varias docenas de RFC, en el verano de 1970 el grupo resurgió con una
Versión preliminar de un protocolo para comunicaciones básicas y sencillas de host a host.

Cuando el “comité de limpieza de fallas” terminó su trabajo un año después, el NWG finalmente
produjo un protocolo completo. Se llamó Protocolo de control de red o NCP.
En enero de 1970, Bob Kahn decidió que, con los primeros cuatro nodos funcionando, era hora de
probar varios escenarios en los que la red podría sufrir fallos congestivos. El tipo de bloqueo que
más le preocupaba, el escenario que le había sugerido a Crowther meses antes, sería causado
por la congestión en un IMP de destino. Había especulado que los buffers de almacenamiento
estarían tan llenos que los paquetes necesarios para reensamblar los mensajes no podrían
fluir hacia un IMP de destino, que a su vez estaría lleno de partes de mensajes desmembrados
en espera de ser completados.
Para probar esa hipótesis y apaciguar a Kahn, Heart sugirió que Kahn y Dave Walden volaran a
Los Ángeles para poner a prueba la cadena. Kahn tenía varios experimentos en mente.
Quería enviar todas las permutaciones posibles de tráfico de IMP a IMP, cambiando el tamaño de
los paquetes y la frecuencia a la que se enviaban, en un intento de inducir un punto muerto.
Walden aceptó porque era el programador práctico que sabía cómo manipular el
código y hacer que los paquetes hicieran lo que Kahn quería que hicieran. Walden se encargó de
reconfigurar los IMP para enviar tráfico en patrones específicos. Podría alargar o truncar los
paquetes, enviarlos cada tres segundos o cada medio segundo. El software IMP, los algoritmos
y todo el diseño iban a sufrir una gran destrucción.
Lo primero que Kahn preparó fue una prueba para demostrar que su temor a un bloqueo por
reensamblaje estaba bien fundado. Tal como Kahn había predicho, al asediar a los IMP con
paquetes, en unos pocos minutos él y Walden pudieron forzar a la red a entrar en catatonia.
"Creo que lo hicimos en los primeros doce paquetes", recordó Kahn. “Todo el asunto se detuvo
por completo”.
Kahn quedó reivindicado. Él y Walden se quedaron varios días y continuaron con los
experimentos. Para Walden, que había pasado tantos meses encerrado en Cambridge
escribiendo código casi en el vacío, fue gratificante ver la red en funcionamiento, incluso si su
objetivo ahora era romperla. Se lo estaba pasando genial. "Yo estaba pirateando para obtener
una paga", recordó Walden. "Me impulsó a aprender todo lo que pudiera y lo más rápido que pudiera".
Kahn y Walden establecieron una rutina. Todas las mañanas se levantaban y desayunaban en el
restaurante Sambo al lado de su hotel en Santa Mónica. Walden aprovechó estas mañanas como
una oportunidad para satisfacer el gusto de su nativo californiano por el jugo de naranja recién
exprimido, todavía una rareza en Boston. Luego condujeron hasta el campus de UCLA y pasaron
todo el día y gran parte de la tarde probando los límites de los IMP. A veces hacían un descanso
para cenar; a veces no se daban cuenta de que la hora de cenar había llegado y pasado. Se tomaron
una noche libre para ver la película M*A*S*H, que acababa de estrenarse.
A menudo se les unía Cerf y, ocasionalmente, también Crocker y Postel. En un momento de la

prueba, Cerf programó el Sigma7 para generar tráfico al IMP y utilizó la máquina host para recopilar
datos sobre los resultados. Esta era la primera vez que trabajaba.
estrechamente con Kahn en un proyecto desafiante, consolidando un vínculo profesional que duraría
muchos años.
Al final de la semana, el cuaderno de Kahn estaba lleno de datos que demostraban su caso. Cuando él y
Walden regresaron a Cambridge, compartieron sus hallazgos con Crowther y Heart.
Crowther no dijo mucho, pero Kahn sospechó que la batería de pruebas le hizo empezar a pensar en el
problema. "De alguna manera, Crowther debe haber registrado en el fondo de su mente que si dos de
nosotros regresamos y reportamos este problema, tal vez hubo un problema", dijo Kahn. De vuelta en el
laboratorio, Crowther construyó una simulación de lo que Kahn y Walden habían hecho en el campo y
descubrió por sí mismo que la red podía bloquearse.
Informó sus hallazgos a Heart un poco abatido, quien le indicó a Crowther que trabajara con Kahn para
solucionar el problema. "Bob se sintió mucho mejor y Frank se sintió un poco peor", dijo Walden sobre
todo el episodio. "Por supuesto, Frank nunca pensó que todo fuera perfecto, pero siempre se
desanimaba cuando las cosas no salían bien".
Heart tenía todos los motivos para pasar por alto los pocos fallos que empezaban a aparecer en la
naciente red. Después de todo, los problemas con el control de la congestión podrían solucionarse. A
mayor escala, la empresa había emprendido un experimento arriesgado, que implicaba ideas y
técnicas nunca antes probadas. Y había funcionado. El hardware funcionó y el software funcionó.
Y las formas únicas en que ARPA llevó a cabo sus negocios y su relación con su contratista también
funcionaron.
Por encima de todo, funcionó el concepto esotérico en el que giraba toda la empresa: la conmutación
de paquetes. Las predicciones de un fracaso total estaban completamente equivocadas.
6
Hackear y gritar
La red era real, pero con sólo cuatro nodos agrupados en la costa oeste, su topología era simple y el
experimento pequeño. Las potencias informáticas de la costa este, como el MIT y el Laboratorio
Lincoln, donde sucedían tantas cosas, no estaban conectadas. El mismo lugar donde Bob Taylor había
soñado despierto con una red, la sala de la terminal ARPA en el Pentágono, aún no estaba cableado.
Tampoco lo estaba BBN. Todos esperaban nuevas máquinas, que Honeywell prometió que estarían
en producción cuando llegó la Navidad de 1969.
Los últimos doce meses habían sido duros para ARPA. El presupuesto de la agencia había alcanzado
un máximo histórico y había entrado en declive. La guerra de Vietnam lo estaba consumiendo todo.
En diciembre de 1969, la ARPA fue expulsada de su sede en el Pentágono y obligada a trasladarse
a un edificio de oficinas alquilado en Arlington, Virginia. El director Stephen Lukasik lo llamó “el
equivalente estadounidense de ser desterrado a Siberia”. La ARPA que alguna vez calificó una bandera
estadounidense emitida por el Pentágono detrás del escritorio del director fue silenciosamente
despojada de tales adornos. A pesar de la baja moral, los funcionarios de la ARPA mantuvieron su
bandera y la exhibieron en la nueva sede, con la esperanza de que nadie importante se diera cuenta
de que sólo tenía cuarenta y ocho estrellas.
La informática siguió siendo la única línea del presupuesto de la agencia que no bajó a principios de los años
setenta. Larry Roberts estaba decidido a ganarse el apoyo de las altas esferas, y lo consiguió. Estaba igualmente
decidido a conseguir que una docena adicional de investigadores principales en todo el país aceptaran la
idea de la red ARPA. Siguió empujando. Mantuvo una presión constante sobre los nuevos sitios para que se
prepararan para el día en que un IMP llegaría a sus puertas con un equipo de BBN para conectar sus
computadoras host a la red. No se trataba de si, sino de cuándo, y Roberts siempre lo planteó de esa manera.
En Cambridge, la actividad en Moulton Street comenzó a adquirir un aire de producción: “la fábrica”, la llamaban
algunos. La mayor parte del esfuerzo se trasladó a la gran sala situada en la parte trasera del edificio bajo con el
muelle de carga donde se recibían las entregas de Honeywell; y allí se configuraba cada nueva máquina
para ser depurada y probada antes de ser enviada al campo. Al mismo tiempo, el equipo de Heart continuó
mejorando rápidamente el diseño del IMP, desarrollando, probando y ajustando el software y el hardware.
Las 516 computadoras quinta, sexta y séptima llegaron de Honeywell en los primeros meses del año.
A finales de marzo se instaló el primer circuito de cross de la red experimental ARPA. La nueva línea de 50
kilobits conectaba el centro de computación de UCLA con el sitio de BBN en Moulton Street, que se convirtió en el
quinto nodo de la red. Y no fue sólo un avance simbólico desde la costa oeste hacia el este (expansión de la
frontera a la inversa); El enlace transcontinental también fue una ayuda inmediata para el mantenimiento
y la resolución de problemas de la red.
En los meses previos a que BBN tuviera su propia máquina y estuviera conectado a la red, lidiar con los
problemas de red en el clúster de cuatro nodos en el oeste era un trabajo realizado por personas que estaban
en el sitio. La mayoría de las veces, eso significaba que alguien en California o Utah pasaba horas hablando
por teléfono a través del país con alguien de BBN, mientras el alma desafortunada que se había ofrecido como
voluntaria para solucionar el problema viajaba entre el teléfono y el IMP para llevar a cabo la comunicación
verbal. instrucciones procedentes de Cambridge. Al principio, el equipo de Heart pasó mucho tiempo
hablando por teléfono y mantuvo una presencia más o menos continua en el campo, guiando como
padres el inicio de la red infantil. En un momento dado, Walden voló a Utah, Stanford, Santa Bárbara y UCLA
para entregar personalmente una nueva versión de software.
Pero cuando se instaló un IMP en BBN a principios de la primavera de 1970, de repente hubo una manera de
enviar datos e informes de estado electrónicamente desde los IMP de la costa oeste directamente a BBN. La
obsesión de Heart por la confiabilidad había dado como resultado algo más que computadoras revestidas de
acero pesado. Su insistencia en construir computadoras robustas (y en mantener el control sobre las computadoras
que puso en el campo) había inspirado al equipo de BBN a inventar una tecnología: mantenimiento
y diagnóstico remotos. El equipo de BBN había diseñado en los IMP y la red la capacidad de controlar estas
máquinas desde lejos. Esto lo usaban tanto para solucionar problemas y, a veces, para arreglar los procesadores
de mensajes por control remoto, como también para vigilar los IMP las veinticuatro horas del día.
Horrorizado como estaba ante la perspectiva de que los estudiantes de posgrado se metieran con sus IMP, Heart
había tratado de construir máquinas que pudieran funcionar en gran medida sin supervisión. Canalizó su obsesión
a inventar este conjunto de herramientas y técnicas de gestión de sistemas notablemente útiles.

Las funciones para el control remoto de la red se habían creado integralmente en todos los diseños
de hardware y software del IMP.
En BBN, en el lado del hardware, se agregó una terminal de teletipo con capacidades de registro al
procesador de mensajes de BBN, junto con luces de advertencia especiales y una alarma audible
para indicar fallas en la red. Al diseñar los IMP, BBN hizo posible conectar en bucle las interfaces de
host y módem de la máquina, para poder realizar pruebas de “bucle invertido”. La prueba de
bucle invertido, que podría realizarse de forma remota, conectó la salida de un IMP a su entrada, aislando
efectivamente al IMP del resto de la red. Esto generó tráfico de prueba a través de la interfaz y
permitió a BBN comparar el tráfico de retorno con el tráfico saliente generado por el IMP.
Las pruebas de bucle fueron extremadamente importantes; proporcionaron una manera de aislar las fuentes de problemas.
Mediante un proceso de eliminación, conectando un componente u otro, BBN podría determinar si el
problema radica en las líneas telefónicas, los módems o el propio IMP. Si el tráfico de prueba completó
el circuito intacto y sin errores, entonces es casi seguro que el problema estuvo en alguna parte
exterior del circuito, muy probablemente en las líneas de la compañía telefónica o en los módems.
Y las pruebas de bucle invertido se realizaron con la suficiente frecuencia que dos de los chicos de
IMP, Ben Barker y Marty Thrope, se volvieron expertos en silbar a lo largo de la línea en la
frecuencia adecuada para imitar las señales que la compañía telefónica usaba para probar las líneas.
Desde la sala de computadoras PDP1 en Moulton Street, donde estaba instalado el equipo de
monitoreo de red de BBN, los chicos de IMP podían saber cuándo un circuito telefónico en cualquier
parte de la red funcionaba mal. Podían ver, por la calidad de los mensajes y paquetes que cruzaban
un circuito, cuándo se degradaba la calidad de la señal, cuándo la línea perdía bits, cuándo
introducía ruido o se desvanecía por completo. Cuando el problema estaba en las líneas telefónicas o
en los módems, se llamaba a la compañía telefónica para solucionarlo.
Los ingenieros de BBN disfrutaban de las oportunidades de asustar al personal de reparación de

la compañía telefónica con su capacidad para detectar y, finalmente, predecir problemas en la
línea desde lejos. Al examinar los datos, BBN a veces podía predecir que una línea estaba a punto de
caerse. Los técnicos de la compañía telefónica nunca habían oído hablar de algo así y no lo tomaron muy bien.
Cuando las pruebas de loopback de BBN determinaron que había problemas en una línea, digamos,
entre Menlo Park (Stanford) y Santa Bárbara, uno de los ingenieros de Heart en Cambridge tomó el
teléfono y llamó a Pacific Bell. "Tienes problemas con la línea entre Menlo Park y Santa Bárbara", decía.
“¿Llamas desde Menlo Park o Santa Bárbara?” preguntaría el técnico de Pacific Bell.
"Estoy en Cambridge, Massachusetts".
"Sí claro."
Finalmente, cuando las llamadas de BBN resultaron absolutamente correctas, la compañía telefónica comenzó a
enviar equipos de reparación para solucionar cualquier problema que BBN hubiera detectado.
Debido a la dificultad de detectar de forma remota fallos de componentes en el sistema

geográficamente disperso, el software de red se volvió más complicado con el tiempo. Entre las
suposiciones básicas hechas por los IMP Guys estaba que la forma más efectiva de detectar fallas era
a través de un mecanismo de notificación activo. Diseñaron su sistema para que cada IMP compilara
periódicamente un informe sobre el estado de su entorno local (número de paquetes manejados por el
IMP, tasas de error en los enlaces, etc.) y enviara el informe a través de la red a un centro de operaciones
de red centralizado. centro que BBN había creado en Cambridge. Luego, el centro integraría los informes
de todos los IMP y construiría una imagen global del estado actual más probable de la red.
En los primeros meses lo llamaron Centro de Control de Red. Pero en realidad no era más que un rincón
bastante pequeño de una oficina de BBN. Y el seguimiento de la red fue informal. El Teletipo de registro se
conectó a través de la propia red a todos los IMP en el campo, y la terminal hizo ruido, tomando informes
de cada IMP cada quince minutos. De vez en cuando, por curiosidad, alguien de BBN entraba y miraba
el registro que se estaba acabando en la máquina, sólo para ver qué estaba pasando con la red. Nadie
tenía la responsabilidad específica de escanear el registro. Nadie verificaba fuera del horario comercial,
por lo que a veces había largos períodos en los que las fallas en las líneas pasaban desapercibidas,
especialmente por la noche. Pero si alguien en un sitio de red realmente llamaba para decir: "Oye,
parece que hay un problema", entonces uno de los chicos de IMP inmediatamente miraba el registro de
Teletipo e intentaba descubrir qué estaba pasando.
El equipo de Heart había diseñado los IMP para que funcionaran sin supervisión tanto como fuera posible,
otorgándoles la capacidad de reiniciarse por sí solos después de un corte de energía o un
accidente. El “cronómetro de vigilancia” fue el componente crucial que desencadenó medidas
autocorrectivas en los IMP. La cadena en su conjunto “se miraba mucho el ombligo todo el tiempo”,
dijo Heart, “enviándonos pequeños mensajes diciéndonos cómo se sentía y qué tipo de cosas estaban
sucediendo y dónde, para que de hecho pudiéramos iniciar el trabajo” si es necesario.
No todo se puede diagnosticar o restablecer el funcionamiento de forma remota. Hubo momentos en

que la gente de BBN notó que un IMP acababa de dejar de ejecutarse, por lo que era necesario
recargar el software. Primero, BBN tendría que alertar a alguien al otro lado de la línea y pedirle que
reinserte una cinta de papel o que accione algunos interruptores y presione el botón de reinicio. Así que
desde Moulton Street tocaban el timbre del “mayordomo”, la centralita telefónica adjunta a cada
IMP, con la esperanza de localizar a alguien. Dado que los IMP estaban instalados en grandes
centros informáticos muy activos, no se sabía quién podría responder.
Fue casi como llamar a un teléfono público. Podrías conseguir un experto o un conserje o algún estudiante
que no tuviera ni idea de lo que estaba pasando. Independientemente de quién contestara el teléfono,
los técnicos de BBN intentarían convencer a esa persona sobre las soluciones necesarias. Incluso a las
personas en los sitios que realmente sabían un par de cosas sobre las computadoras se les pidió, de todos
modos, que siguieran las estrictas instrucciones de BBN.
“Recuerdo haber pasado ocasionalmente entre media hora y una hora con el teléfono pegado a mi oído”,
recordó Cerf, cuya discapacidad auditiva hizo que no fuera amigo del teléfono en primer lugar, “siguiendo
instrucciones de alguien en BBN que me decía: 'Pulsa'. este botón.
Dale la vuelta a esta cosa. Introduzca estas cosas para tratar de descubrir qué salió mal y hacer que todo
vuelva a funcionar”. En un cuaderno, BBN mantuvo una lista detallada de sitios, ubicaciones exactas para
cada máquina, y contactos en las distintas ubicaciones, que en al menos un caso incluían al guardia del edificio
como recurso de último recurso.
Tan pronto como se instaló el IMP Número Cinco en BBN, el equipo intensificó su programa de pruebas para
medir el rendimiento de la red y sus limitaciones. Todo el mundo estaba interesado en saber qué tan bien
funcionaría la red en diversos escenarios y si resistiría cargas extremadamente pesadas. Pero los ingenieros
de BBN no dejaron de irritarse cuando Len Kleinrock y otros en el Centro de Medición de Redes de UCLA
intentaron deliberadamente bloquear la red. Las pruebas descubrieron errores e inspiraron
correcciones. Aún así, una cosa era obvia: con un tráfico moderado, la red era tan rápida como BBN había
predicho que sería. BBN informó a Roberts que la nueva red podría describirse como un "sistema de
comunicaciones tenso". Es decir, los mensajes que ingresaban a la red no mostraban tendencia a perderse.
"Observamos que los mensajes no vagan por la red, incluso con altas cargas de tráfico", escribió el equipo
de BBN en uno de sus informes técnicos periódicos.
En el verano de 1970, las máquinas número seis, siete, ocho y nueve habían sido extraídas de Honeywell y
ahora estaban operando en el MIT, RAND, System Development Corp. y Harvard. AT&T había reemplazado
el primer enlace a través del país con una nueva línea de 50 kilobits que unía BBN con RAND. Un
segundo enlace a través del país conectaba el MIT y la Universidad de Utah. La red ARPA estaba creciendo a
un ritmo de aproximadamente un nodo por mes.
Un día de 1970, un camión de reparto de Honeywell se detuvo en el muelle de carga de Moulton Street
y comenzó a retroceder para descargar otra computadora 516 nueva. Alertado de la llegada del camión, Severo
Ornstein salió corriendo por la puerta, hizo una rápida inspección de la máquina mientras aún estaba en el
camión y despidió en voz alta al conductor. Heart, que había salido de su oficina para ver a qué se debía todo
el alboroto, se quedó mirando, desconcertado, cómo Ornstein le decía al conductor que diera media vuelta y
condujera la máquina de regreso a Honeywell; Estaba rechazando la entrega.
Ornstein estaba harto de entregas tardías y equipos incompletos y defectuosos. Devolver el camión causó
revuelo en Honeywell, dijo. Pero por una vez su atención se centró. BBN no aceptaría otro Honeywell 516
hasta que se aclararan algunas cosas. Las dificultades habían ido creciendo. Para el equipo de
Heart, la relación con Honeywell parecía más una pulseada que una asociación. “Nos seguían enviando
máquinas que tenían los mismos errores de siempre”, recordó Ornstein. Después del incidente en el muelle
de carga, comenzó a ir a Honeywell con regularidad para inspeccionar cada máquina nueva antes de enviarla
a BBN.
Al poco tiempo, Honeywell había reunido a su equipo de construcción de IMP y estaba produciendo máquinas
aceptables. Los IMP se entregaron al Laboratorio Lincoln y a Stanford y, a finales de año, la Universidad
CarnegieMellon y la Universidad Case Western Reserve también estaban conectadas a la red. En ese
momento, se habían escrito cientos de revisiones menores en el software IMP. El hardware había sido ajustado
y modernizado. La compañía telefónica, haciendo su parte, tenía ahora catorce enlaces de 50 kilobits
instalados en la red.
Las herramientas de gestión de redes y diagnóstico remoto de BBN también estaban experimentando constantes
mejora. ARPA había ampliado el contrato de BBN para seguir produciendo IMP y gestionar el centro de
control, y todo estaba funcionando.
El nivel de actividad en el centro de seguimiento de BBN aumentó. Con la constante expansión de la

red, los informes de diagnóstico que llegaban a BBN estaban empezando a inflarse y volverse
engorrosos. Los chicos de IMP tenían dificultades para mantenerse al tanto de los datos, escanear la
copia impresa del registro de Teletipo y localizar señales de problemas. Necesitaban una ama de
llaves. Entonces decidieron conectar una máquina de repuesto, el primer prototipo IMP de BBN, a la red
ARPA, donde funcionaría como una máquina anfitriona detrás del IMP BBN normal. Esta nueva
máquina host se utilizaría para ayudar a procesar los informes de estado de la red. Los programadores
de BBN escribieron un nuevo código para compilar resúmenes cada hora de los mensajes de estado
de IMP más frecuentes que ahora se acumulaban a razón de uno por minuto de cada IMP. La
suposición operativa del código era que ninguna noticia era mala: si el Centro de control de red no recibía un
mensaje de estado de un IMP durante tres minutos, la lectura del estado de la red indicaría que ese IMP
estaba muerto. Esta y otras mejoras facilitaron la detección de cambios de estado importantes en la
red.
Era noviembre de 1970 cuando Alex McKenzie regresó a BBN después de una breve licencia. Él y su
esposa habían pasado seis meses acampando en Europa. En el poco tiempo que estuvo fuera, el
proyecto de la red había avanzado espectacularmente. Ahora instalado de nuevo en Cambridge, McKenzie
se dio cuenta de la importancia que tenía para BBN gestionar la red como si fuera una empresa de servicios
eléctricos. Eso significaba que tendría que ocurrir una reordenación de ciertos supuestos fundamentales.
Había llegado el momento de pasar la red de un modo experimental a uno operativo, razonó. Y
McKenzie comenzó a inculcar esa opinión a todos sus colegas.
Organizado y meticuloso, McKenzie parecía el candidato perfecto para hacerse cargo del Centro de
control de red de BBN, y Heart lo nombró para la tarea.
Otros cambios culturales se estaban gestando en torno a BBN. La sensibilidad de McKenzie hacia el
proyecto de red estaba en sintonía con una empresa en general más orientada a los negocios. La propia
BBN estaba creciendo. Uno o dos años después de que McKenzie impulsara el funcionamiento de
la red como una empresa de servicios públicos, BBN había comprado Superior Laundry en la parte más
transitada de Moulton Street y lo derribó para dejar espacio para un nuevo edificio de siete pisos para la sede.
Finalmente, el Centro de Control de Red y el resto de la división de Heart se trasladaron al quinto piso
de las nuevas dependencias. Arquitectónicamente, el estilo del impresionante edificio nuevo sugería
sutilmente una elegante fortaleza. Construido en el apogeo del movimiento contra la guerra a principios de
la década de 1970, reflejaba la conciencia corporativa emergente de BBN sobre las amenazas
antisistema a las empresas involucradas en la contratación del Departamento de Defensa de Estados
Unidos. El edificio no tenía ventanas en la planta baja, donde se ubicaba un gran centro de cómputo.
También tenía un estacionamiento en el sótano diseñado de manera que el edificio en sí estuviera apartado,
rodeado por un importante foso sin agua, permitiendo el acceso a la puerta principal solo a través de un corto puente peatonal.
En el quinto piso, el Centro de Control de Red ocupaba una gran sala con grandes ventanales que daban
al norte, a las colinas más allá de Cambridge. El equipo de Heart, compuesto por unas treinta personas,
estaba distribuido en oficinas modernas y laboratorios bien equipados por todo el piso. La división de Heart
tenía el único piso del edificio con su propia pequeña cocina escondida en un pasillo central, una petición
especial de Heart, que algún día tenía la intención de equiparla con una máquina de café expreso italiana
con calidad de restaurante.
Dominando una gran pared del centro de control había un mapa lógico de la red.
Construido con piezas magnéticas móviles sobre un fondo de metal, el mapa era un diagrama de cableado
que mostraba todos los IMP, computadoras host y enlaces, indicados por marcadores cuadrados, redondos
y triangulares. Los códigos de colores y los punteros indicaban el estado de cada IMP, nodo y enlace. De un
vistazo, los operadores podían saber qué líneas o IMP estaban caídas y hacia dónde se dirigía el tráfico
alrededor de los puntos problemáticos. Además de la información crítica, de vez en cuando se podía
pegar un chiste o una caricatura con un imán, como si el mapa de control fuera la gran puerta de un
refrigerador.
Una de las tareas principales del NCC era publicar actualizaciones de software y recargar los
programas operativos IMP cuando fuera necesario. Los operadores utilizaron un ingenioso esquema
cooperativo mediante el cual cada IMP descargaba el software de un vecino. Todos los martes, de 7:00 a 9:00
a. m., BBN tenía la red reservada para distribución de software, pruebas de red y mantenimiento. En estas
dos horas, los operadores de la NCC podrían hacer que cada IMP de la red ejecute una nueva versión de
software. Todas las nuevas versiones de los códigos operativos IMP finalmente se distribuyeron de esta
manera. El proceso de propagación electrónica comenzaría en Cambridge cuando se descargara un nuevo
programa de software en un sitio cercano, que a su vez descargaría el paquete de software a otro vecino, por
orden de los operadores.
El método también tenía potencial restaurador. Si se descubriera que el programa operativo de un IMP
estaba destruido, el IMP podría enviar una solicitud de recarga del programa a un IMP vecino.
El IMP que respondiera enviaría una copia de su propio programa.
Sintonia FINA
Otros grandes cambios también se produjeron en el segundo año de funcionamiento de la red. BBN y
ARPA decidieron que el robusto Honeywell 516, que reflejaba demasiada preocupación por la confiabilidad,
era una expresión de exageración. También era caro. El 516 costaba aproximadamente un 20 por ciento
más que una versión más nueva de la computadora, la Honeywell 316, que no estaba disponible en forma
robusta. Ben Barker, quien permaneció íntimamente involucrado en el mantenimiento y solución de
problemas de más de una docena de IMP que se encuentran actualmente en el campo, en realidad llegó
a la conclusión de que los gabinetes del robusto 516 eran una fuente de confiabilidad reducida, porque
obstaculizaban lo que deberían haber sido tareas de mantenimiento de rutina fácilmente realizadas.
Honeywell tenía contrato para encargarse del mantenimiento de rutina. Pero aquí también tardaron en
aceptar la visión emergente de BBN (el modelo de utilidad de McKenzie) sobre cómo debería funcionar una
red informática. Hubo períodos en los que el tiempo de inactividad de los IMP promedió hasta un 3 o 4
por ciento mensual. Si un servicio eléctrico o un sistema telefónico estuvieran fuera de servicio la mayor parte
del tiempo (un día al mes), su rendimiento se consideraría abismal. Pero hubo que convencer a
Honeywell para que imaginara hacia dónde querían ir BBN y ARPA con la red.
"Recuerdo una gran reunión en la que repasamos los números con los chicos de Honeywell",
recordó Barker. “Los chicos de Honeywell dijeron: 'Espera un momento. ¿Estás diciendo que estas máquinas
están fuera de servicio entre media hora y una hora al día? Eso es como, uh, tres
porcentaje de tiempo de inactividad. Quiere decir que estas máquinas funcionan el noventa y siete por ciento
del tiempo, las veinticuatro horas del día. ¿¡Cómo estás haciendo eso!?'”
El tiempo de inactividad del 3 por ciento que sorprendió a Honeywell fue, en palabras de BBN,
"síndrome de falla prolongada del hardware". Los procedimientos normales de llamar y trabajar con los
ingenieros de campo de Honeywell no habían solucionado varios de estos "fallos persistentes",
informó BBN. Estaban particularmente preocupados por los problemas en varios sitios en el área de
Washington, DC.
Frustrado por los recurrentes problemas de mantenimiento, Roberts amenazó, muy vagamente, con
cancelar el contrato de BBN. Barker finalmente acudió a Heart y le propuso permitirle formar un equipo
de mantenimiento dirigido por BBN, con un personal de campo adecuado para el mantenimiento
periódico y un “bombero” experto itinerante. Pero McKenzie se opuso rotundamente a la idea, no porque
estuviera contento con cómo iban las cosas con Honeywell sino porque temía que Barker sólo empeorara
las cosas. McKenzie, un hombre exigente, reaccionaba ante el estilo personal y descuidado de Barker; dijo
que la oficina de Barker parecía como si un camión de basura hubiera sido empujado hacia ella y vaciado de
su contenido, y de hecho era una imagen apropiada. Pocos pondrían en duda que la oficina de Barker era,
en un buen día, un desastre total.
Tampoco cuestionarían la agudeza de sus conocimientos y habilidades técnicas. Entonces, en el intercambio,
Barker hizo un esfuerzo concertado para mantener limpia su oficina y Heart le asignó el trabajo de crear y
dirigir un equipo de mantenimiento de crack.
Dejando a un lado el mantenimiento, la confianza de Heart en la confiabilidad intrínseca de la red había

aumentado durante el primer año. Había visto a los IMP funcionando con éxito en el campo. Su equipo
había superado sus pruebas iniciales. Después de un tiempo también se mostró un poco más tranquilo
respecto a la confiabilidad de los investigadores y estudiantes de posgrado en el lugar. Como consecuencia,
la última versión robusta del Honeywell 516 llegó a Moulton Street a finales de 1970 y finalmente se envió
como IMP Número Quince, con destino a Burroughs Corporation en Paoli, Pensilvania. Casi al mismo
tiempo, la Universidad de Illinois en UrbanaChampaign recibió la máquina número doce, que se había
retrasado.
A estas alturas, BBN había recibido el visto bueno de ARPA para dedicarse a otro esfuerzo intensivo de
ingeniería: diseñar un prototipo de IMP basado en 316. Honeywell prometió la entrega de la máquina
a principios de 1971. La transición al más ligero 316 IMP fue sólo una parte de un cambio
estructural en desarrollo en la red ARPA.
Durante meses, el equipo de Heart y Roberts habían estado discutiendo la posibilidad de conectar muchos
usuarios nuevos a la red sin pasar por una computadora host. Parecía que podían hacer posible iniciar sesión
en la red, llegar a un host distante y controlar recursos remotos a través de un dispositivo terminal
simple (un teletipo o un CRT con teclado).
conectado directamente a un IMP. El nuevo esquema eliminaría la necesidad de una computadora
host entre cada usuario y la subred IMP. Todo lo que necesitarías para que funcione sería un terminal tonto
conectado a un IMP. Esto abriría muchos nuevos puntos de acceso.
Si esto pudiera resolverse técnicamente, entonces cientos o incluso miles de usuarios más podrían obtener
acceso a la red sin proximidad física a una computadora host. Entonces, la red ya no sería sólo un
experimento para los científicos informáticos incondicionales con cuentas de mainframe, sino que estaría
abierta a toda una panoplia de usuarios más ocasionales: oficiales militares,
burócratas gubernamentales, administradores universitarios, estudiantes, que serían incorporados a la comunidad

de networking. Esto acercaría al mundo un paso más hacia la realización de la visión de Licklider de la
computadora como facilitadora de la comunicación y la interacción humana.
Pero ni los IMP originales ni los nuevos 316 IMP podían admitir más de cuatro interfaces de host. Ninguna
máquina podía acomodar una conexión terminal. Para que el nuevo concepto sea viable, el equipo de Heart
tendría que construir una nueva interfaz que pudiera manejar docenas de líneas terminales que alimentan el
IMP y la red. Sintiendo el valor de ir en esta nueva dirección, BBN lanzó un esfuerzo acelerado para diseñar un
controlador de terminal que pudiera gestionar el tráfico generado por una gran cantidad de dispositivos terminales
conectados directamente o mediante líneas de acceso telefónico. El nuevo dispositivo se llamó simplemente
Terminal IMP o TIP.
En seis meses, BBN y Honeywell completaron el diseño y la construcción de dos nuevos prototipos de
máquinas basadas en el 316. El primero era un IMP básico, el otro un TIP que incluía un controlador multilínea
capaz de gestionar el tráfico de señales de hasta sesenta tres terminales a la vez. Todos los dispositivos
terminales conectados a un TIP serían direccionables como si pertenecieran a un único host en la red. En
la trastienda donde BBN recibía las entregas, el equipo de Heart había instalado una pequeña celda de prueba
para depurar las máquinas entrantes; la última de las 516 máquinas había entrado por la puerta a un ritmo
bastante constante cada cuatro semanas, y en cualquier momento podía haber dos o tres máquinas, a veces
más, conectadas entre sí para probar su rendimiento y simular el tráfico de la red. Estaba previsto que los primeros
cuatro TIP entregables llegaran a BBN a finales del verano de 1971.
Todo parecía funcionar según lo previsto. BBN comenzó a explorar la gama de dispositivos terminales que
podrían conectarse a la red. Las opciones iban desde pantallas gráficas CRT hasta impresoras de líneas
rápidas y lentas, pantallas alfanuméricas y terminales tipo teletipo. El equipo también estaba considerando
cómo conectarse a lectores de tarjetas, grabadoras de cinta magnética y otros dispositivos periféricos.
Aún más pruebas de algoritmos de enrutamiento, pruebas de rendimiento, pruebas de esquemas de control
de flujo y pruebas de diagnóstico remoto continuaron ocupando al equipo de BBN diariamente, semana tras
semana, lo que condujo a mejoras constantes en su tecnología de conmutación de paquetes.
El Centro de control de red siguió expandiéndose con la red. La presión para mantener la red creció. Se convirtió
en una parte constante del contrato de ARPA con la empresa, y pronto el centro contó con personal las 24
horas, los siete días de la semana. En un momento, la NCC actualizó algunos equipos y agregó un marcador
telefónico automático al sistema. El marcador automático estaba destinado específicamente a monitorear el
estado de los módems distribuidos por la red.
Había docenas de módems que manejaban el tráfico de datos hacia los TIP. Los solucionadores
de problemas de BBN hicieron que el marcador automático ejecutara una prueba simple: el marcador estaba
programado para llamar a cada módem una vez al día y escuchar una respuesta. Si un módem respondía
con un silbido, sus signos vitales se consideraban normales. Cualquier módem que no responda o devuelva
señales incorrectamente aparece en un informe de problemas.
En un momento, el personal de NCC detectó un módem en particular que parecía no funcionar

correctamente cada vez que el marcador automático realizaba su verificación. Alguien sugirió hacer una llamada.
a través del marcador automático hasta el módem problemático, mientras un técnico escuchaba; tal vez
podría diagnosticar la señal que regresa. Entonces hizo la llamada, escuchó hasta que el módem contestó
y escuchó una voz enojada al otro lado de la línea. Antes de colgar el auricular, se dice en innumerables
versiones que la voz dijo: "¡Oye, Martha, soy ese loco del silbato otra vez!".
El control de la congestión, uno de los problemáticos problemas demostrados por los

experimentos de Kahn, había sido atacado y mejorado. BBN había rediseñado el esquema para
reservar suficiente espacio en los buffers de memoria IMP para reensamblar los paquetes entrantes. Se
reservaría una cantidad específica de espacio de reensamblaje para cada mensaje en un IMP de destino
antes de que se permitiera que el mensaje ingrese a la red. El IMP emisor lo comprobaría y, si le decían
que no había suficiente espacio disponible en los buffers del IMP de destino, la RFNM (Solicitud de
siguiente mensaje) se retrasaba. La solución no fue diferente al trato que muchos pasajeros de una
aerolínea han experimentado cuando un avión no puede despegar porque el mal tiempo en el aeropuerto
de destino impide que el avión aterrice. El pasajero se sienta en el suelo y espera una apertura en el
destino. En las simulaciones, el nuevo esquema logró evitar la inserción de más tráfico en la red del que
el IMP de destino podía manejar.
Si el desarrollo de la red fuera a avanzar a un ritmo constante ahora, sería necesaria una coordinación
más estrecha entre el esfuerzo de BBN para introducir la Terminal IMP y el esfuerzo del Grupo de
Trabajo de Red para desarrollar protocolos. Entonces el equipo de Heart decidió involucrarse
mucho más profundamente en el trabajo del Grupo de Trabajo de la Red. A mediados de 1971, BBN
se había incorporado a los comités del NWG (McKenzie era el representante de BBN) que trabajaban
en el protocolo de host a host, el protocolo de transferencia de archivos y el protocolo Telnet.
Aunque llevó más de un año elaborarlo, el protocolo Telnet era un procedimiento relativamente sencillo. Era
un mecanismo mínimo que permitía una comunicación básica entre dos máquinas host. Los primeros cuatro
nodos habían conectado cuatro máquinas diferentes, mientras que otros sitios host ofrecían una mezcla
adicional de computadoras incompatibles, desde la DEC PDP10 hasta grandes IBM, pasando por
máquinas Honeywell y Xerox. Telnet fue concebido para superar diferencias simples, como establecer una
conexión y determinar qué tipo de conjunto de caracteres utilizar. Fueron TIP y Telnet juntos los que
allanaron el camino para una rápida expansión de la red.
Las transferencias de archivos fueron el siguiente desafío. Durante un par de años, media docena de
investigadores habían estado intentando llegar a un protocolo de transferencia de archivos, o FTP,
aceptable. El protocolo de transferencia de archivos especificaba el formato de los archivos de datos
comercializados a través de la red. La transferencia de archivos era una especie de fuerza vital para la red.
Las transferencias de archivos eran el equivalente digital de la respiración: inhalación de datos,
exhalación de datos, hasta el infinito. FTP hizo posible compartir archivos entre máquinas. Mover
archivos puede parecer sencillo, pero las diferencias entre las máquinas lo hacen todo lo contrario. FTP
fue la primera aplicación que permitió que dos máquinas cooperaran como pares en lugar de
tratar a una como una terminal para la otra. Llevar esta funcionalidad a la red dependía de que el
grupo de trabajo FTP creara un producto final funcional.
El presidente del grupo, Abhay Bhushan, estudiante graduado del MIT y arquitecto de sistemas,
era un experto en Multics, un sistema operativo ambicioso y complejo. Bhushan había estudiado los
problemas de la multitarea en una sola computadora. El siguiente paso fue transferir bloques
de datos en un sistema multicomputador como la red ARPA.
Durante los seis meses que pasó trabajando en el protocolo de transferencia de archivos, el equipo
normalmente se reunió cara a cara en sesiones regulares del Grupo de Trabajo de la Red. Pero
también utilizó con frecuencia teleconferencias por computadora en tiempo real. Todos los miembros del
equipo se conectaban a la vez, desde Palo Alto, Cambridge, Los Ángeles y Salt Lake, y durante una
o dos horas seguidas intercambiaban comentarios de un lado a otro. Conversar a través de teclados
y terminales era menos espontáneo que hablar, pero Bhushan creía que imponía claridad en su
pensamiento. También tenía la ventaja de crear un registro de su trabajo. A principios de julio de
1972, se dieron los toques finales al FTP y Jon Postel, ahora editor y distribuidor de Requests For
Comments, lo publicó como RFC 354.
Mostrándolo
El único problema real con esta red ahora era la carga. Es decir, no hubo mucho.
Al principio el tráfico era ligero porque los protocolos llegaban tarde. Ahora, en un día normal, los
canales estaban prácticamente vacíos. En el otoño de 1971, la red transportaba un promedio de sólo
675.000 paquetes por día, apenas más del 2 por ciento de su capacidad de 30 millones de paquetes por
día. El Centro de Medición de Redes de UCLA continuó generando tráfico de prueba para probar
las debilidades de todos los algoritmos de la red. Pero no había suficiente tráfico natural en la red
para superar realmente los límites de los esquemas de enrutamiento y anticongestión.
Hubo algunos usos tempranos interesantes. Los programadores de SRI estaban utilizando el compilador
PDP10 de Utah como preparación para instalar su propio PDP10 y generaron la mayor cantidad
de tráfico. Jon Postel de UCLA estaba utilizando la red para ejecutar el sistema onLine de SRI.
Bob Metcalfe, un estudiante graduado de Harvard que trabaja en el MIT, y un amigo, Danny Cohen,
que enseñaba en Harvard, realizaron uno de los primeros experimentos más interesantes a través de la red.
Metcalfe y Cohen utilizaron el PDP10 de Harvard para simular el aterrizaje de un portaaviones y luego
mostraron la imagen en una terminal de gráficos en el MIT. Los gráficos se procesaron en el MIT y los
resultados (la vista de la cabina de vuelo del portaaviones) se enviaron de regreso a través de la red
ARPA al PDP1 en Harvard, que también los mostró. El experimento demostró que un programa
podía moverse por la red a una velocidad tan alta que se aproximaba al tiempo real. Metcalfe y otros
redactaron un RFC para anunciar el triunfo y lo titularon “Momentos históricos en el networking”.
Otros no tuvieron tanto éxito. Hubo un primer intento de idear algo llamado servicio de reconfiguración
de datos; fue un intento fallido de escribir un lenguaje de programación que interpretara archivos
incompatibles en diferentes computadoras.
La red ARPA, sin embargo, era prácticamente desconocida en todas partes excepto en el santuario
interior de la comunidad de investigación informática. Y sólo para una pequeña porción de la
comunidad informática, cuyo interés de investigación eran las redes, la red ARPA se estaba convirtiendo
en una herramienta utilizable. Para ellos fue un experimento fantástico, pero había que participar en él.
cosas como la teoría de colas o la teoría de las comunicaciones para apreciarlo. Si, por otra parte, su
trabajo era en inteligencia artificial o robótica o gráficos por computadora o casi cualquier otra cosa que la
comunidad estuviera investigando, la utilidad de este gran sistema transcontinental de conmutación de
paquetes aún no se había descubierto. A nadie se le había ocurrido una demostración útil de cómo
compartir recursos; Los protocolos para que funcionara ni siquiera estaban implementados.
La red ARPA era una red creciente de enlaces y nodos, y eso era todo, como un sistema de
autopistas sin coches.
Sin embargo, aparentemente en toda la comunidad había ricos recursos para compartir.
CarnegieMellon tenía un departamento de inteligencia artificial de primer nivel y aplicaciones únicas que lo
acompañaban. Stanford tenía un grupo de robótica extraordinario. En teoría, en casi todos los sitios se
podría aportar a la red alguna capacidad única.
Si la red alguna vez iba a convertirse en algo más que un banco de pruebas para el tráfico artificial
generado por los Centros de Control y Medición de la Red, era necesario difundir su potencial. Larry
Roberts sabía que había llegado el momento de realizar una manifestación pública.
Roberts estaba en el comité de programa de la primera Conferencia Internacional sobre Comunicaciones
Informáticas, que se celebraría en Washington en octubre de 1972. Marcó con un círculo la fecha y
llamó a Bob Kahn, que todavía estaba en BBN, y le pidió que organizara una demostración de la red ARPA.
como única exhibición en la reunión. Faltaba aproximadamente un año para la conferencia.
Roberts le pidió a Kahn que comenzara a planificar de inmediato. De hecho, Kahn ya había
planeado dejar BBN e ir a trabajar para Roberts en ARPA. Pero ambos hombres decidieron que sería una
buena idea que Kahn se quedara en BBN por un tiempo para planificar la manifestación.
El primer paso de Kahn fue reclutar a Al Vezza, del Proyecto MAC del MIT, para que lo ayudara. Vezza
siempre causó una buena impresión. Era sociable e impecablemente elocuente; Tenía una mente
científica aguda y instintos administrativos de primer nivel. Entre los dos hombres probablemente no
había ningún proyecto informático clave en la comunidad de investigación estadounidense que no conocieran
o un actor clave al que no pudieran persuadir para que se uniera a ellos.
A mediados de 1971, Kahn y Vezza convocaron a un pequeño grupo de unos ocho investigadores
principales de todo el país para asistir a una reunión en el Tech Square del MIT en Cambridge. Presentaron
la idea de una demostración atractiva y altamente accesible de los recursos más interesantes de la
comunidad, accesibles a través de la red. Vezza sabía que tendría que ser una demostración interactiva en
vivo si quería tener algún impacto. Alguien en la reunión argumentó enérgicamente a favor de una
presentación grabada en vídeo, para evitar fallos informáticos durante la exposición. Vezza se mostró
incrédulo y argumentó con la misma firmeza que cualquier cosa que no fuera una demostración práctica en
vivo utilizando equipos y software reales indicaría incertidumbre y un posible fracaso de todo el
experimento de la red ARPA.
Tenía que hacerse en tiempo real, tenía que ser algo que cualquiera pudiera tocar y controlar simplemente
sentado frente a una terminal. Fue una apuesta. Todavía no había mucha experiencia operativa con
los protocolos Telnet y File Transfer, que los participantes tendrían que utilizar. Y esto aumentó el riesgo de
que la manifestación fracasara. Pero si la demostración tenía éxito, demostraría que la red no sólo era real
sino también útil.
Durante los siguientes nueve meses, Kahn y Vezza viajaron por el país con el presupuesto de Roberts.
“Había muchos callejones sin salida”, recuerda Vezza. Se reunieron con decenas de vendedores en el
industria informática, pidiendo a cada uno que participara llevando sus propios terminales al
Washington Hilton, donde se celebraría la reunión y donde un TIP los conectaría a la red ARPA. Roberts
estaba haciendo arreglos para que AT&T trajera dos líneas de 50 kilobits al hotel. El plan era realizar
demostraciones en tantas máquinas como fuera posible, conectadas a tantos sitios como fuera posible. Los
organizadores invitarían a los asistentes a la conferencia a entrar, sentarse, iniciar sesión y utilizar los
recursos de la red.
Se llevaron a cabo decenas de reuniones en los distintos sitios de la red para diseñar escenarios interesantes.
Se firmaron equipos de estudiantes de posgrado e investigadores principales. Y casi en cuanto lo hicieron,
empezaron a sentir cierto pánico. Para lograrlo, tendrían que intensificar sus esfuerzos para finalizar las
herramientas y protocolos de red inacabados. Roberts, muy acertadamente, había previsto la
probabilidad de que programar una manifestación pública muy visible para octubre de 1972
aumentaría la presión sobre la comunidad para que se movilizara y se asegurara de que la red funcionara
sin problemas para esa fecha. Kahn también reconoció que la manifestación fue “organizada
para obligar a los usuarios finales a comprender la utilidad de la red”.
En el otoño de 1971, BBN tenía un prototipo de TIP funcionando en 50 Moulton Street. Otros dos TIP
estaban operativos en otras partes de la red, que en ese momento constaban de sólo diecinueve nodos.
Los TIP, basados en el Honeywell 316, eran completamente compatibles con todos los 516 más antiguos.
A principios de 1972 se habían instalado varios 316 IMP y TIP adicionales y la parte central de la red
entre las costas este y oeste estaba comenzando a llenarse. En agosto de 1972, se había agregado una
tercera línea a campo traviesa. Además de los IMP dispersos por el centro del país, ahora había grupos
de IMP en cuatro áreas geográficas: Boston; Washington DC; San Francisco; y Los Ángeles. A
medida que se acercaba la demostración del ICCC, había veintinueve nodos en lo que ahora se conocía
ampliamente como ARPANET o, más a menudo, simplemente la Red.
Y la gente en los sitios luchaba como loca. Se habían involucrado decenas de importantes
contribuyentes de todas las comunidades académicas y de investigación de Estados Unidos. Se estaban
realizando intensos esfuerzos para depurar aplicaciones y poner en funcionamiento los ordenadores host
a tiempo para la demostración pública. Todos los fabricantes de terminales habían sido invitados a demostrar
que sus equipos podían funcionar con ARPANET: hacían cola para mostrar más de cuarenta terminales
informáticos diferentes en la demostración. Vezza negoció con un proveedor local en el área de
Washington, DC, quien acordó prestar una gran sección de piso elevado antiestático para sala de
computadoras para su instalación en la sala de reuniones del Hilton, donde se ubicarían el TIP y las
terminales. AT&T prometió que cumpliría con el enlace de datos. Instalar un circuito de este tipo en cualquier
lugar en menos de seis meses no fue un asunto menor, y ciertamente no lo fue para AT&T tener esa línea
en el Hilton a medida que se acercaba el ICCC.
Varios días antes de la reunión, el equipo de networking y la gente comenzaron a llegar al hotel. Kahn y
Vezza habían elaborado un plano. El TIP estaba ubicado en una sección de piso elevado en el
centro de la gran sala de reuniones. Alrededor del perímetro de la sala habría docenas de terminales,
prácticamente no había dos iguales. Se necesitarían un par de días para colocar todo el equipo en su
lugar, conectarlo, encenderlo y revisarlo. En cuestión de horas, la habitación era una maraña de
cables y gente.
hablando parloteo técnico. Los técnicos tendían cables por todas partes. Los miembros del equipo de
Heart estaban por todas partes, herramientas en mano, profundamente comprometidos en ayudar a
los distintos fabricantes de terminales a modificar los cables conectores en cada uno de la multitud de
dispositivos terminales, para que cada uno pudiera conectarse al TIP. Se dedicaron horas a pelar cables,
volver a cablear los conectores, reconectar, probar y depurar.
Muchos de los participantes estaban trabajando a un ritmo frenético. Muchos habían hecho las maletas
mientras aún terminaban sus proyectos y vinieron a Washington para darle los toques finales. Fue la
primera vez que toda la comunidad se presentó en un solo lugar al mismo tiempo. "Si alguien
hubiera lanzado una bomba sobre el Washington Hilton, habría destruido casi toda la comunidad de
networking en Estados Unidos en ese momento", observó Kahn. Sin mencionar a la comunidad
internacional, porque incluso Donald Davies, padre del término “conmutación de paquetes”, había venido
desde Inglaterra para ver cómo funcionaría todo esto. "Fue simplemente una experiencia increíble", dijo Vint
Cerf. “Cortando y gritando y gritando y diciendo: 'No, no...'. . . te equivocaste en este. "Obtener todos los
detalles correctamente".
Al final del sábado (la conferencia se inauguró el lunes), el BBN TIP era como un rey en un trono de alambre
que recorría todos los rincones de la sala. AT&T había hecho su trabajo y apareció en el momento adecuado
con la línea adecuada. El domingo fue otro día frenético de preparación, pero ahora el TIP estaba en acción,
por lo que la gente comenzaba a ejecutar programas y hacer sus comprobaciones finales. Muchos no
terminaron hasta el domingo por la tarde, justo antes de que se programara una demostración
preliminar para un grupo de personalidades: un círculo de congresistas de Washington, funcionarios del
Pentágono y otros. Aproximadamente a las seis de la tarde, minutos antes de que se abrieran las
puertas, Vezza estaba cerca del TIP cuando Metcalfe dijo, sin ninguna urgencia en su voz: "¡Estamos
perdiendo paquetes!".
Vezza miró a McKenzie, que estaba allí mismo: "Alex, ¿qué cambió?"
McKenzie buscó la línea directa de Cambridge y gritó por teléfono: “¡Sácalo!

¡Sacarlo!"
El Centro de Control de Red había estado observando y monitoreando una línea ligeramente defectuosa en
la red durante los últimos días. Pensaron que habían resuelto el problema esa tarde y habían agregado el
circuito nuevamente a la red. Treinta segundos después de la llamada de McKenzie, los operadores del
NCC eliminaron el enlace y los paquetes volvieron a fluir sin problemas en el TIP.
La tecnología de gestión remota de BBN nunca había pasado por su mejor momento.
Más tarde esa noche, Jon Postel estaba en la sala de exhibición sentado frente a un teclado, conectado al
host de UCLA. Su equipo había diseñado una demostración en la que alguien en Washington podía
abrir un archivo en Boston a través de la computadora central en Los Ángeles. La idea era imprimir luego el
archivo en la sala de exposiciones del Hilton. Cuando Postel envió el archivo a la imprenta que estaba a
su lado, no pasó nada. Miró alrededor de la habitación.
Hubo muchas otras demostraciones, una de las cuales fue una pequeña tortuga robótica construida en el
MIT. La tortuga fue construida para demostrar cómo se podría escribir un programa de computadora
para dirigir el movimiento de una máquina. Los niños podrían escribir sus propios programas en el
lenguaje LOGO que dijera “ir a la izquierda, ir a la derecha, avanzar, retroceder, moverse hacia los lados” y cuando el
Si se ejecutara el programa, la tortuga haría eso. En ese momento, sin embargo, la tortuga estaba
saltando arriba y abajo, retorciéndose y sacudiéndose locamente. En lugar de enviar el archivo de
Postel a la impresora, el sistema lo envió accidentalmente al puerto de tortugas y el robot ofreció
obedientemente su interpretación de lo que consideraba comandos de movimiento.
Bob Metcalfe, un entusiasta estudiante de posgrado, se había propuesto escribir un folleto para
acompañar las manifestaciones. Describía diecinueve escenarios para usar ARPANET, enumeraba
recursos en varios sitios y mostraba cómo iniciar sesión en un host remoto, cómo obtener acceso a
una de las aplicaciones y cómo controlar un programa o participar en algún tipo de comunicación
interactiva a través de ARPANET. la red. Hubo varias partidas de ajedrez, un cuestionario interactivo
sobre la geografía de América del Sur, una forma de leer las noticias de Associated Press a través de la
red y muchos otros juegos, herramientas y demostraciones. Una de las aplicaciones más prácticas
simuló un escenario de control de tráfico aéreo en el que la responsabilidad de monitorear el vuelo de
un avión se transfiere automáticamente de una computadora a otra, que representa diferentes centros de
control de tráfico aéreo, a medida que el avión cruza fronteras geográficas. El libro de escenarios de
Metcalfe fue diseñado para guiar paso a paso a los participantes, la mayoría de los cuales sabían poco
sobre ARPANET, a través de cada demostración.
El lunes por la mañana, los informáticos de ARPANET esperaban con impaciencia a su público.
Cuando se acercaron curiosos asistentes a la conferencia, los chicos de la cadena, como los testigos de
Jehová que repartían ejemplares de La Atalaya, les pusieron en las manos el libro de escenarios de
Metcalfe y los hicieron pasar a la sala. Aunque era posible seguir las instrucciones, para todos, excepto
para los iniciados, el libro de escenarios era bastante incomprensible y era fácil estropear el sistema. Un
hombre se sentó frente a una terminal y escribió una instrucción del libro. Por alguna razón u otra, el host
al que intentaba comunicarse no funcionaba o se equivocó. El mensaje volvió: "ANFITRIÓN MUERTO".
"Ay dios mío. ¡Lo he matado! el exclamó. Después de eso no volvería a tocar una terminal.
Sucedieron otras cosas divertidas. Dos personas habían iniciado sesión en la Universidad de Utah. Uno
vio que alguien más que conocía pero que nunca había conocido estaba conectado. Estaba en modo
de conversación, así que escribió: "¿Dónde estás?". El otro respondió: "Bueno, estoy en Washington".
“¿En qué parte de Washington?” "En el Hilton". "Bueno, yo también estoy en el Hilton". Los dos resultaron
estar a sólo unos metros el uno del otro.
Algunas cosas no fueron tan divertidas. Como autor del libro de escenarios, Metcalfe fue elegido para
llevar a diez ejecutivos de AT&T a un recorrido virtual por ARPANET. Era una visión extraña: el
joven Metcalfe, con su gran barba roja, mostrando a diez empresarios vestidos con rayas diplomáticas
de AT&T alrededor de la red. En medio de la manifestación las computadoras colapsaron. Fue la primera
y única vez que las computadoras fallaron. La primera reacción de los ejecutivos de la compañía
telefónica fue reírse.
“Levanté la vista con dolor”, dijo Metcalfe, “y los sorprendí sonriendo, encantados de que la conmutación
de paquetes fuera inestable. Esto nunca lo olvidaré. Les confirmó que la tecnología de conmutación de
circuitos había llegado para quedarse, y que esta cosa de conmutación de paquetes era un juguete
poco confiable que nunca tendría mucho impacto en el mundo comercial, y ahora podían regresar a su
hogar en Nueva Jersey. Para mí estaba claro que estaban enredados en el pasado”.
Si hubieran mirado más allá del desafortunado Metcalfe y la demostración fallida, los ejecutivos de
AT&T habrían visto la exuberancia en otros rincones de la sala. La conmutación de paquetes
no sólo funcionó, sino que hizo posibles cosas maravillosas.
Algunas de las demostraciones más ingeniosas involucraron programas de conversación en

inglés. Se trataba de programas elaborados construidos para involucrar al usuario en un
diálogo verbal con una máquina. Se exhibieron cuatro programas, dos de los cuales ofrecieron una
visión especialmente fascinante de la informática interactiva.
PARRY, el primero de estos conversadores virtuales, imitó el sistema de creencias de un

psicótico paranoico. Mantuvo su parte de la conversación ofreciendo respuestas preparadas a
declaraciones que creía entender. Por lo demás, su respuesta fue evasiva.
PARRY fue una creación del Dr. Kenneth Colby de la Universidad de Stanford.
The Doctor fue otro programa conversacional, basado en ELIZA, un programa de lenguaje
natural escrito por Joseph Weizenbaum del MIT. El Doctor, que imitaba el comportamiento
de un psiquiatra, se mostró bastante más tímido que PARRY. El Doctor aceptó declaraciones y
luego intentó producir nuevas oraciones basadas en las palabras y la sintaxis del otro
interlocutor. Si bien la conversación resultante fue completamente banal, los usuarios a menudo se
sorprendieron por lo realista que parecía la calidad de sus conversaciones con el Doctor.
"La gente se sentaba e interactuaba con esta cosa", observó Cerf. "Y a veces pedían a otras
personas que salieran de la habitación porque pensaban que estaban teniendo una
conversación privada".
Cerf y otros habían jugado con la idea de preparar al paranoico de Colby para que tuviera
una “sesión” con el psiquiatra. Apenas unas semanas antes de la demostración de ICCC,
PARRY se reunió con el Doctor para una conversación inusual a través de ARPANET, en un
experimento orquestado en UCLA. Quizás marcó el origen, en el sentido más estricto, de todo chat
informático. No hubo intervención humana en el diálogo. PARRY estaba funcionando en el laboratorio
de inteligencia artificial de Stanford, el Doctor estaba funcionando en una máquina en BBN, y en
UCLA sus entradas y salidas estaban interconectadas a través de ARPANET, mientras los
operadores se sentaban y observaban.
“Buenas noches”, dijo el doctor. “Cuéntame tus problemas. Termine la entrada con un punto o un
signo de interrogación”.
“A veces la gente me pone de los nervios”, respondió PARRY.
"No estoy seguro de entenderte".
"Deberías prestar más atención".
"Supongo que deberías prestar más atención".
"Tienes derecho a tener tu propia opinión".

“¿Qué te hace pensar que tengo derecho a tener mi propia opinión?”
"Me molesta estar rodeado de gente en general".
"Continúa por favor."
"Fui a la pista en Bay Meadows hace un tiempo".
"¿Por qué dices eso ahora?"
"Hay muchas apuestas deshonestas allí".
"Apuesto a los caballos".
“¿Qué te sugiere eso?”
“Fui a las carreras”.
“¿Qué más te gustaría discutir?”
"El juego no ha sido más que un problema para mí".
"He tenido experiencia con delincuentes apostando en la pista".
"No estoy seguro de entenderte completamente".
"¿Sabes algo sobre casas de apuestas?"
“¿Qué te hace pensar que sé algo sobre casas de apuestas?”
"Un corredor de apuestas no me pagó ni una sola vez".
"Le di una paliza al corredor de apuestas que no pagó y pensé que podría usar a sus amigos del
inframundo para vengarse de mí".
"¿De quién estás hablando realmente?"
“¿Alguna vez has pensado realmente en la MAFIA?”
“Supongamos que alguna vez pensaste realmente en la MAFIA”.
"Hablemos de otra cosa."

“Sigues preguntándome lo mismo, ¿por qué no cambias de tema?”
“¿Por qué tienes esas preguntas en mente?
"Creí haberte dicho que la gente me pone de los nervios".
“¿Tus nervios?”
"Preferiría no hablar más de eso".
"¿Te gustaría hablar sobre tus nervios?"
"Supongo que sí."
“Insistes demasiado en las mismas preguntas”.
“¿Qué te sugiere esa similitud?”
"No te entiendo."
"¿Desearías no haberme entendido?"
"Ya es hora de que muestres algo de interés en mis sentimientos".
"¿Oh? ¿Mostré algún interés en tus sentimientos?
"Te ayudaré si confío en ti".
“¿Quieres confiar en mí?”
"Tal vez sí tal vez no."
"No pareces muy seguro".
"En mi opinión, tienes una mente unidireccional".
“¿Qué te hace pensar que tengo una mente unidireccional?”
"Solía ir a la pista todas las semanas".
“¿Qué más te gustaría discutir?
"Eso es algo en lo que no quiero entrar".
"No es asunto tuyo".
"¿Por qué estás preocupado por mi negocio?"

"No confío en extraños".
“¿Realmente no confías en extraños?”
"Cambiemos de tema."
“¿Qué te pasa que sigues molestándome con esto?”
"Eres un verdadero fastidio".
"¿Te agrada creer que soy un verdadero fastidio?"
"Ya he tenido suficiente de esto".
"Adiós."
“Ha sido un placer.
“Miedo = 4.2223001
“Ira = 10
“Desconfianza = 12.650703
"Eso es $399,29, por favor".
Cientos de personas participaron en la manifestación de la ICCC durante dos días y medio.

Ejecutivos, ingenieros y técnicos de las industrias de telecomunicaciones e informática, un buen
número de ellos, entraron a la sala escépticos ante ARPANET y la conmutación de paquetes.
Muchos se marcharon creyendo que, después de todo, la tecnología podría ser real. En su mayor parte,
las cuarenta y pico terminales funcionaron, los recursos fueron atractivos, el TIP funcionó
espectacularmente y ARPANET cobró vida. "Era casi como si la industria ferroviaria no
creyera que los aviones realmente podían volar hasta que vieron uno en vuelo", dijo Kahn.
La demostración del ICCC hizo más para establecer la viabilidad de la conmutación de paquetes
que cualquier otra cosa anterior. Como resultado, la comunidad ARPANET adquirió un sentido mucho
mayor de sí misma, de su tecnología y de los recursos a su disposición. Los fabricantes de computadoras
se dieron cuenta de que podría surgir un mercado. “La sensación en esa sala no era de miedo o
preocupación”, dijo Len Kleinrock. “Fue emoción. Quiero decir, aquí podíamos mostrarlo, sabíamos
que funcionaría. Incluso si fallaba, estas cosas se podían arreglar. Era un
experiencia maravillosamente emocionante.” Roberts había mostrado una confianza constante. Había
conseguido lo que quería, un esfuerzo más solidificado, los cimientos de una comunidad, algo sobre lo
que podía construir. Los esfuerzos y el pánico que precedieron al evento dieron sus frutos. Y ese día,
incluso BBN y Honeywell se llevaban bien.
Bob Kahn acababa de dedicar un año de su vida a demostrar que compartir recursos a través de una red
realmente podía funcionar. Pero en algún momento durante el evento, se volvió hacia un colega y le
comentó: "Sabes, todo el mundo realmente usa esto para el correo electrónico".
7
Correo electrónico
Una tarde de septiembre de 1973, Len Kleinrock estaba desempaquetando sus maletas cuando
descubrió que había olvidado su navaja. Acababa de regresar a su casa en Los Ángeles desde
Brighton, Inglaterra, donde había dejado la navaja en el baño de un dormitorio de la Universidad de Sussex.
Una afeitadora eléctrica normal y corriente no supuso una gran pérdida. “Pero era mío”, recordó, “y
quería recuperarlo”.
Kleinrock acababa de llegar de una conferencia sobre informática y comunicaciones. La conferencia

reunió a científicos de varios países, algunos de los cuales habían comenzado a desarrollar redes
digitales bajo los auspicios de sus propios gobiernos. Pero ARPANET del gobierno de Estados Unidos
fue, con mucho, el experimento de red más grande y sofisticado del mundo, y la comunidad
internacional agradeció la oportunidad de ver el proyecto demostrado. Los organizadores de la conferencia
también decidieron aprovechar la ocasión para probar la transmisión de paquetes de datos vía
satélite. Para la conferencia se había establecido un enlace temporal desde Estados Unidos con
Brighton. Los paquetes viajaron a través de un enlace satelital desde Virginia a una estación terrestre en
Cornwall, en Goonhilly Downs cerca de Land's End, y desde allí se instaló una línea telefónica exclusiva
para conectarse con la Universidad de Londres. Desde Londres se hizo un último salto hasta Brighton,
donde la gente tuvo la oportunidad de utilizar ARPANET como si estuvieran sentados en una
oficina de Cambridge, Massachusetts, o Menlo Park, California.
Kleinrock había regresado a Estados Unidos un día antes, así que cuando se dio cuenta de que había
olvidado su navaja de afeitar, pensó que tal vez encontraría a alguien todavía en la conferencia para
recuperarla. Había un software útil en la red llamado ejecutivo de intercambio de recursos, o RSEXEC.
Si escribía “dónde fulano de tal”, RSEXEC buscaba fulano de tal buscando en la lista “quién”, una lista de
todos los que iniciaron sesión, en cada sitio. Podrías localizar a una persona en la red de esta
manera si estuviera conectada en ese momento. "Me pregunté qué maníaco se conectaría a las tres de
la madrugada". Kleinrock lo recordó. Fue a su terminal y escribió "dónde roberts".
Unos minutos más tarde, la terminal de Kleinrock mostró la respuesta. De hecho, Larry Roberts
todavía estaba en Brighton, despierto y en ese momento conectado con un anfitrión de BBN
en Cambridge. En la pantalla de Kleinrock también apareció un número de teletipo de Roberts, información
suficiente para que pudiera tocar electrónicamente a su colega en el hombro desde Los Ángeles.
"Todo lo que tuve que hacer fue establecer una conexión de teletipo a BBN", dijo Kleinrock. Se conectó
con Roberts usando TALK, lo que les permitió conversar escribiendo en una mitad de una pantalla
dividida mientras leían en la otra. Los dos amigos intercambiaron saludos. “Le pregunté si podía
recuperar la navaja. Él dijo: 'Claro, no hay problema'”. Al día siguiente, Danny Cohen, un amigo
en común que había estado en la conferencia y había regresado a Los Ángeles, devolvió la navaja.
No había reglas formales que restringieran el uso de ARPANET por parte de aquellos con acceso
autorizado. La travesura de recuperación de la navaja de Kleinrock no fue la primera vez que alguien
superó los parámetros oficiales al usar la red. La gente enviaba cada vez más mensajes personales.
Se rumoreaba que incluso se habían hecho uno o dos negocios de drogas con algunos de los IMP
en el norte de California. Aún así, acceder a ARPANET para buscar una afeitadora a través de líneas
internacionales era un poco como viajar como polizón en un portaaviones.
Después de todo, ARPANET era un centro de investigación federal oficial y no algo con lo que se pudiera
jugar. Kleinrock tuvo la sensación de que el truco que había realizado estaba ligeramente fuera de límites.
“Fue emocionante. Sentí que estaba estirando la red”.
ARPANET no fue pensado como un sistema de mensajes. En la mente de sus inventores, la red estaba
destinada a compartir recursos, punto. El hecho de que muy poca de su capacidad fuera realmente
utilizada para compartir recursos fue un hecho que pronto quedó sumergido en la marea del correo
electrónico. Entre 1972 y principios de la década de 1980, miles de primeros usuarios descubrieron el
correo electrónico, o correo de red, como se lo denominaba. La década dio origen a muchas de
las características perdurables de la cultura digital moderna: llamas, emoticones, el signo @, debates
sobre la libertad de expresión y la privacidad, y una búsqueda insomne de mejoras técnicas y
acuerdos sobre los fundamentos técnicos de todo esto. Al principio, el correo electrónico era difícil de
utilizar, pero a finales de los años 1970 los grandes problemas habían sido superados. El gran
aumento del tráfico de mensajes se convertiría en la fuerza inicial más importante del crecimiento y
desarrollo de la red. El correo electrónico fue para ARPANET lo que la compra de Luisiana fue para los jóvenes Estados Unidos.
Las cosas solo mejoraron a medida que la red creció y la tecnología convergió con la torrencial tendencia
humana a hablar.
El correo electrónico se convertiría en el registro duradero del ciberespacio. Así como el LP se inventó
para conocedores y audiófilos pero generó toda una industria, el correo electrónico creció primero entre la
comunidad de élite de científicos informáticos en ARPANET y luego floreció como plancton en Internet.
Fue en el momento en que Kleinrock cogió su navaja cuando los tabúes comenzaron a caer y el tono
del tráfico de mensajes en la Red empezó a relajarse.
Como artefacto cultural, el correo electrónico pertenece a una categoría entre el arte encontrado y los
accidentes afortunados. Los creadores de ARPANET no tuvieron una gran visión para la
invención de un sistema de manejo de mensajes que rodeara la Tierra. Pero una vez que se
instalaron las primeras docenas de nodos, los primeros usuarios convirtieron el sistema de
computadoras conectadas en una herramienta de comunicación tanto personal como profesional.
Usar ARPANET como sistema de correo sofisticado fue simplemente un buen truco. En aquellos días, la
piratería no tenía nada que ver con un comportamiento malicioso o destructivo; un buen truco era una
programación creativa o inspirada. Los mejores hackers eran profesionales. Red entrometida y maliciosa
A los usuarios, de los cuales prácticamente no había ninguno al principio, se les llamó primero “aleatorios de red”
o “aleatorios de red” o simplemente “aleatorios”. Pasaría otra década antes de que se le diera mala fama al
hacking.
En la década anterior a ARPANET, los científicos informáticos habían ideado formas de intercambiar mensajes
electrónicos dentro de un sistema de tiempo compartido. Cada uno de los investigadores del mismo sistema de
tiempo compartido tenía un archivo designado, como una bandeja de entrada, en la máquina central. Los
colegas podían enviar mensajes electrónicos cortos al buzón de otra persona, donde sólo el destinatario podía
leerlos. Los mensajes se pueden dejar y recoger en cualquier momento. Era conveniente, dado el
horario extraño que tenía la gente. La gente de un mismo laboratorio enviaba desfiles de frases ingeniosas de
un lado a otro, así como memorandos y borradores de artículos más extensos.
El primero de estos programas, llamado MAILBOX, se instaló a principios de la década de 1960 en el Sistema
de Tiempo Compartido Compatible del MIT. Buzones de correo similares se convirtieron en una característica
estándar de casi todos los sistemas de tiempo compartido creados a partir de entonces. En lugares donde la
gente estaba dispersa, los programadores que trabajaban a cientos de metros de distancia podían intercambiar
mensajes sin tener que levantarse de sus escritorios. Pero a menudo, intercambiar mensajes en una sola máquina
o dominio se convertía en un ejercicio superfluo, como dos personas que usan walkietalkies para conversar en
una cabina de una sola habitación. La gente todavía se levantaba de sus escritorios y caminaba por el pasillo para hablar.
Un usuario dijo: "Nunca olvidaré a un colega que, mientras trabajaba en la oficina de al lado, me enviaba
constantemente correos electrónicos y nunca dejaba de sorprenderlo cuando me levantaba y caminaba hacia
la puerta de al lado para responderle".
En virtud de su alcance geográfico, la red ARPA cambió todo eso, convirtiendo el correo electrónico de un juguete
interesante en una herramienta útil. Las tendencias de la comunidad ARPANET
eran fuertemente democráticas, con una especie de vena anárquica.
Los primeros usuarios de ARPANET generaban constantemente un flujo constante de nuevas ideas, jugueteaban
con las antiguas, empujaban, tiraban o incitaban a su red a hacer esto o aquello, generando una atmósfera
de caos creativo. El arte de la programación informática les dio espacio para riffs interminables y variaciones
sobre cualquier tema. Uno de los temas principales fue el correo electrónico.
La primera entrega de correo electrónico con dos máquinas se realizó un día de 1972 por un tranquilo ingeniero,
Ray Tomlinson, de BBN. Algún tiempo antes, Tomlinson había escrito un programa de correo para Tenex, el
sistema operativo desarrollado por BBN que, a estas alturas, se ejecutaba en la mayoría de las máquinas PDP10
de ARPANET. El programa de correo se escribió en dos partes: para enviar mensajes, se usaba un programa
llamado SNDMSG; para recibir correo, usarías la otra parte llamadaREADMAIL. En realidad, no tenía la
intención de que el programa se usara en ARPANET. Al igual que otros programas de buzones de correo de la
época, fue creado para sistemas de tiempo compartido y diseñado sólo para manejar el correo localmente,
dentro de PDP10 individuales, no entre ellos.
Pero Tomlinson, un experimentador empedernido, decidió aprovechar la posibilidad de tener dos ordenadores
PDP10 instalados en la oficina de Cambridge; de hecho, eran las mismas máquinas que BBN estaba usando
para conectarse a ARPANET. Semanas antes, Tomlinson había escrito un protocolo experimental de
transferencia de archivos llamado CPYNET. Ahora modificó el programa para que pudiera transportar un mensaje
de correo desde una máquina y colocarlo en un archivo sobre otro. Cuando
lo intentó y envió correo de un PDP10 a otro, el pequeño truco funcionó y, aunque su correo en realidad no había
salido a la red abierta, había cruzado una división histórica importante. El CPYNEThack de Tomlinson fue
un gran avance; ahora ya no había nada que impidiera que el correo electrónico cruzara la red en general. Aunque
en términos técnicos el programa de Tomlinson era trivial, culturalmente era revolucionario.
“SENDMSG abrió la puerta”, dijo Dave Crocker, el hermano menor de Steve Crocker y pionero del correo electrónico.
"Creó la primera interconectividad, luego todos tomaron la iniciativa a partir de ahí".
Pero ¿cómo conseguir que este invento se agote en la red? La respuesta está en el protocolo de transferencia
de archivos. En julio de 1972, una tarde en Tech Square del MIT, mientras Abhay Bhushan escribía las
especificaciones finales para el protocolo de transferencia de archivos ARPANET, alguien sugirió incorporar los
programas de correo electrónico de Tomlinson al producto final. ¿Por qué no? Si los mensajes electrónicos pudieran
viajar en CPYNET, también podrían viajar en el protocolo de transferencia de archivos. Bhushan y otros
idearon algunas modificaciones. En agosto, cuando Jon Postel recibió un RFC que describía la función de correo
electrónico, pensó: "Ahora tenemos un buen truco". Los primeros gemelos de ARPANET que manejan correo
electrónico, llamados MAIL y MLFL, cobraron vida.
Tomlinson se hizo muy conocido por SNDMSG y CPYNET. Pero se hizo más conocido por una decisión brillante (la
llamó obvia) que tomó mientras escribía esos programas. Necesitaba una forma de separar, en la dirección de
correo electrónico, el nombre del usuario de la máquina en la que se encontraba el usuario. ¿Cómo debería
denotarse eso? Quería un carácter que, bajo ninguna circunstancia imaginable, se encontrara en el nombre del
usuario. Miró el teclado que estaba usando, un Teletipo Modelo 33, que casi todos los usuarios de la Red también
usaban. Además de las letras y los números, había alrededor de una docena de signos de puntuación. “Llegué
primero, así que pude elegir la puntuación que quisiera”, dijo Tomlinson. "Elegí el signo @". El carácter también
tenía la ventaja de significar "en" la institución designada. No tenía idea de que estaba creando un ícono para el mundo
cableado.
Stephen Lukasik, físico que dirigió ARPA de 1971 a 1975, estuvo entre los primeros usuarios y grandes defensores del
correo en red. De hecho, su parte favorita de ARPA era la Oficina de Técnicas de Procesamiento de Información de
Larry Roberts. Lukasik había comenzado su carrera en la década de 1950 trabajando para BBN y MIT como estudiante
de posgrado. Se unió a ARPA en 1966 para trabajar en la detección de pruebas nucleares y había presenciado
la creación de ARPANET. Durante su ascenso a la dirección, Lukasik había luchado especialmente duro para proteger
la financiación de la comunidad informática. ARPA estaba bajo presión para realizar trabajos relacionados con la
defensa. Consideró que la informática era una tecnología más fundamental pero importante y la defendió como tal
ante el Congreso.
Pero a veces las cosas iban demasiado lejos. Como director, caminaba mucho y visitaba a la gente en sus oficinas.
Un día estaba en la oficina del IPT cuando notó una carpeta encima de un archivador. Su cubierta naranja (“no
es mi color favorito”) le llamó la atención.
La carpeta estaba etiquetada como “Coreografía asistida por computadora”. Contenía informes de progreso sobre un
proyecto que utilizaba los movimientos de los bailarines para mapear los movimientos humanos por computadora. "Fui
balístico”, dijo. Podía imaginarse el titular: EL PENTÁGONO FINANCIA LA INVESTIGACIÓN

EN LA DANZA.
Lukasik pidió a su personal que dijera a los científicos: "si van a hacer algo que parezca estar a cuarenta
mil millas de la defensa, por favor no incluyan nuestro nombre". Entendía la investigación y no
le importaba si lo hacían, pero no quería que se jactaran de ello. Steve Crocker, ahora director de
programas de IPTO que trabaja con Roberts, se alegró de no ser él quien supervisara el proyecto de
automatización de la danza. Pero tenía un pequeño problema con los investigadores que estaba
financiando en el Laboratorio de Inteligencia Artificial de Stanford. "En visitas aleatorias sin previo
aviso, me mostraban con orgullo la simulación cuadrafónica del laboratorio de una mosca
zumbando, que consumía el veinticinco por ciento de los recursos informáticos allí", dijo Crocker.
Una de las primeras cosas que Lukasik hizo al ser nombrado jefe de la agencia fue conseguir que
Roberts le diera una dirección de correo electrónico y acceso a ARPANET. Era inusual que alguien
que no fuera informático estuviera interesado en utilizar el correo de red. , y es más inusual que
alguien se vuelva tan dependiente de él como lo hizo Lukasik.
Lukasik, un viajero frecuente, rara vez abordaba un avión sin cargar con su terminal Texas Instruments
“portátil” de treinta libras con un acoplador acústico, para poder marcar y revisar sus mensajes desde
la carretera. "Realmente lo usé para gestionar ARPA", recuerda Lukasik.
“Estaba en una reunión y cada hora marcaba mi correo. Animé a todos los que estaban a la
vista a usarlo”. Se lo impuso a todos los directores de su oficina y ellos se lo impusieron a los demás.
Los gerentes de ARPA notaron que el correo electrónico era la forma más fácil de comunicarse con el
jefe y la forma más rápida de obtener su rápida aprobación.
Lukasik y Roberts tenían una relación excelente, en parte porque ambos eran pensadores
analíticos y en parte porque Roberts siempre respondía rápidamente cualquier pregunta que Lukasik
tuviera sobre sus proyectos. “Si teníamos una reunión el martes por la tarde y enviaba a Larry con
algunas preguntas que responder, él regresaba al día siguiente para otra reunión con algo más
que respuestas. Tendría tendencias, proyecciones y comparaciones”.
Entonces Lukasik descubrió lo que estaba pasando y la utilidad del correo electrónico quedó más
clara que nunca. Normalmente, Roberts salía de la oficina de Lukasik, regresaba a su propia oficina y
enviaba mensajes a los expertos sobre el tema en cuestión, quienes a su vez respondían las
preguntas a sus estudiantes de posgrado. Veinticuatro horas y una ráfaga de correos electrónicos
más tarde, el problema se había resuelto varias veces. "La forma en que trabajaba Larry
fue el argumento por excelencia a favor de una red informática", dijo Lukasik. Durante el mandato de
Lukasik, el presupuesto anual de Roberts casi se duplicó, de 27 millones de dólares a 44 millones de dólares.
En 1973, Lukasik encargó un estudio ARPA que encontró que tres cuartas partes de todo el
tráfico en ARPANET era correo electrónico. Para entonces, enviar correos electrónicos era un
proceso sencillo y casi sin problemas. Sin embargo, intentar leerlo o responder era otra cosa:
funcional pero nada fácil. El texto simplemente aparecía en la pantalla o salía de la impresora, y nada
separaba los mensajes. Para llegar al último, había que repasarlos todos de nuevo. Para muchos
usuarios, la única forma de leer el correo era activar el teletipo e imprimir secuencias de texto.
Redactar mensajes era realmente una molestia, porque las herramientas para texto
la edición era primitiva. Y no había ninguna función de “respuesta” para el correo electrónico; para responder,
había que empezar un nuevo mensaje desde cero.
Lukasik, que odiaba tirar cualquier cosa, empezaba a sentirse frustrado por el volumen de correo electrónico
que se acumulaba en su bandeja de entrada. Fue a Roberts. “Dije: 'Larry, este correo electrónico es fantástico,
¡pero es un desastre!'”, recordó Lukasik. “Al estilo típico de Larry, vino al día siguiente y dijo: 'Steve, escribí un
código para ti que puede ayudarte'. Y me mostró cómo obtener un menú de mensajes, archivarlos o eliminarlos.
" Roberts acababa de escribir el primer software de gestión de correo.
Roberts llamó a su programa RD, que significa "leer". A todos en ARPANET les encantó y a casi todos se
les ocurrieron variaciones de RD: un ajuste aquí y un pellizco allá. Una cascada de nuevos programas de
manejo de correo basados en el sistema operativo Tenex fluyó hacia la red: NRD, WRD, BANANARD (“banana”
era la jerga de los programadores para “cool” o “hip”), HG, MAILSYS, XMAIL. . . y siguieron viniendo. Muy pronto,
los principales operadores de la red empezaron a sudar. Eran como malabaristas que habían lanzado demasiado
al aire. Necesitaban más uniformidad en estos programas. ¿Nadie estaba prestando atención a los estándares?
Por razones no relacionadas con el correo electrónico pero evidentes para todos los que usaban la
red a diario, ocasionalmente la red simplemente se volvía loca. O, como dijo una persona, se “arrugó”.
Un problema en una máquina podría desencadenar un efecto dominó en todo el sistema. Caso concreto: el día de
Navidad de 1973, encierro. El IMP de Harvard desarrolló un fallo de hardware que tuvo el extraño efecto de leer
todos los ceros en las tablas de enrutamiento, informando así a otros IMP de todo el país que Harvard acababa
de convertirse en la ruta más corta (cero saltos) hacia cualquier destino en ARPANET. La avalancha de paquetes
hacia Harvard fue impresionante.
Los usuarios notarían un bloqueo como ese. Todo se detuvo. “Harvard se convirtió en un agujero negro”, dijo John
McQuillan, entonces estudiante de posgrado de Harvard. "Todo el tráfico iba a Harvard y, como en un
agujero negro, no salía ninguna información". Ben Barker le había presentado a McQuillan las
operaciones de red y había ayudado a conectar el PDP1 de Harvard. Mientras terminaba su doctorado,
McQuillan fue contratado para mejorar el software del Centro de control de red de BBN. El día de Navidad, cuando
los ceros de Harvard fueron enviados a las tablas de enrutamiento de todo el país, incluso el tráfico de
control utilizado por BBN para diagnosticar y depurar el sistema fue absorbido por la “órbita gravitacional” del
IMP defectuoso de Harvard. Los operadores de BBN tuvieron que “cauterizar” (cortar esa parte de) la red,
depurarla y luego volver a activarla.
Al igual que una empresa de servicios públicos, BBN estaba desarrollando rápidamente los medios para
hacer frente a estos sucesos. Y hubo relativamente pocos fallos en toda la red y ninguno duró mucho tiempo.
Los martes, los días en que BBN tenía el ARPANET reservado para las tareas domésticas, McQuillan llegaba
a las seis de la mañana. Crowther y Walden habían dejado de programar los IMP.
Entre 1972 y 1974, McQuillan asumió la responsabilidad principal de revisar los códigos y diseñar los
procedimientos de publicación. Dirigió el equipo que escribió todo el nuevo software IMP y realizó los
lanzamientos en la red. Construyó redes de prueba “bastante elaboradas”
en el laboratorio BBN, donde simuló escenarios de falla, obligando a la red de prueba a fallar para
poder aprender a hacer que ARPANET sea más a prueba de fallas.
"Simplemente sabes que las computadoras se enfrentarán a tormentas eléctricas, fallas de energía,
errores de software y errores de hardware, y el conserje se tropezará con el cable de alimentación,
y cualquier cosa que se te ocurra podría suceder", dijo McQuillan. . Pero de todos los problemas
potenciales, el problema en el algoritmo de enrutamiento se consideró el peor.
A pesar de su elegancia y simplicidad, el algoritmo de enrutamiento original escrito por Crowther tenía
fallas, porque aunque era sencillo, en cierto sentido el esquema era demasiado primitivo para el
tráfico pesado. Era un problema conocido, pero no importó hasta que la red llegó a un punto en el
que el uso intensivo y una gran cantidad de nodos comenzaron a sobrecargar el esquema de
enrutamiento. "Esto no empezó a suceder hasta que la red creció", dijo McQuillan. “Cuando era muy
pequeño, todos los protocolos básicos funcionaban. Pero cuando es pequeño, casi cualquier cosa
funcionará”. Sabían que cuando el sistema alcanzara los cincuenta o sesenta nodos, el antiguo
algoritmo no sería capaz de proporcionar actualizaciones de enrutamiento lo suficientemente
rápido y tendrían un gran lío entre manos. McQuillan se propuso “hacer completamente a prueba de
balas” el cálculo para que “seguira funcionando frente a problemas 'imposibles'”.
En dos años, con muchos lanzamientos, McQuillan reemplazó los algoritmos de enrutamiento, la
forma en que funcionaban los reconocimientos y, finalmente, todo el programa operativo IMP. Creó
un algoritmo completamente diferente para enviar información sobre cambios en la red muy
rápidamente a todos los IMP para que no tomaran malas decisiones de enrutamiento. Y eliminó
los escenarios de punto muerto, en parte eliminando de la ecuación los infames RFNM.
"Conocía todas las computadoras de la red", dijo McQuillan. “Sabía dónde estaban, cuáles eran sus
números y quiénes estaban allí, y los conocía a todos por su nombre”. A estas alturas había casi
cincuenta IMP en ARPANET.
•••
Algo en un sistema de correo, digital o no, resulta atractivo para quienes tienen cierto temperamento
inconformista. Quizás porque debe haber reglas, algunas personas siempre intentarán violarlas.
Estaba el tipo inteligente, por ejemplo, que se salió con la suya utilizando el Servicio Postal de
Estados Unidos para enviar ladrillos, uno por uno, a Alaska, hasta que tuvo suficiente allí para
construirse una casa; era la forma más barata de enviarlos desde los cuarenta y ocho estados más
bajos. O está la tía Em, que adorna los paquetes que envía a sus lejanos sobrinos y sobrinas con
ilustraciones fantasiosas, para probablemente diversión más que consternación de los
empleados postales. En algún lugar de un grueso libro con letra pequeña se encuentran las regulaciones
postales oficiales relativas al correo estadounidense: qué se puede enviar, qué no y cómo. Pero
dentro de ciertos límites, se entregan todo tipo de paquetes, porque los empleados del correo humanos
pueden adaptarse a una latitud bastante amplia de inconformidad.
Pero imaginemos una oficina de correos local en algún lugar que decidiera hacerlo sola, estableciendo sus propias
reglas para direccionar, empaquetar, sellar y clasificar el correo. Imagínese si esa oficina de correos corrupta
decidiera inventar su propio conjunto de códigos postales. Imaginemos un gran número de oficinas de correos
asumiendo la responsabilidad de inventar nuevas reglas. Imaginemos una confusión generalizada. Correo
su manejo exige cierta conformidad y, como las computadoras son menos tolerantes a los fallos que los
seres humanos, el correo electrónico exige en voz alta.
Las primeras disputas en ARPANET sobre los intentos de imponer encabezados de mensajes estándar fueron
típicas de otros debates sobre estándares de la industria informática que surgieron más tarde. Pero
debido a que la lucha por los estándares del correo electrónico fue una de las primeras fuentes de tensión
real en la comunidad, se destacó.
En 1973, un comité ad hoc dirigido por Bhushan del MIT intentó poner cierto orden en la implementación
de nuevos programas de correo electrónico. Todo el mundo sabía que, a largo plazo, se necesitaba un
protocolo de transmisión de correo independiente del FTP. El correo de red estaba cobrando vida propia.
Tenía sus propios problemas técnicos. Y no podía permanecer pegado al FTP para siempre. Pero por ahora,
simplemente estandarizar los encabezados de correo ya era suficiente dolor de cabeza.
Los paquetes de datos en ARPANET ya tenían algo llamado encabezados, pero eran completamente
diferentes de los encabezados de los correos electrónicos. Los encabezados de los paquetes de datos eran
bits codificados leídos estrictamente por los IMP, indicándoles cómo manejar cada paquete a medida
que llegaba. Sin embargo, en el contexto del correo electrónico, el encabezado se refiere a una gran cantidad
de información que se encuentra en la parte superior de cada mensaje de correo electrónico. La idea era que
cierta información siempre debería aparecer en la parte superior de los mensajes en un formato específico, en
realidad solo un elaborado localizador de fecha y hora, incluyendo información como la hora en que se
envió y entregó un mensaje, la ruta que recorrió, otros destinatarios a quienes fue enviado y más. El
comité de Bhushan también sugirió una sintaxis que facilitaría la lectura de los encabezados sin la ayuda
de mucho procesamiento de mensajes especial.
Los encabezados no siempre fueron algo visto únicamente por el usuario. Algunos campos de
encabezado fueron procesados por sistemas receptores, programados para manejar significados reservados
y una sintaxis muy definida. Si el programa destinatario de alguna manera malinterpretara el encabezado
del remitente, los resultados podrían ser sumamente frustrantes. El programa lector podría detenerse en seco
o mostrar un mensaje de error. Las fechas, por ejemplo, se especificaban de una manera particular
y las desviaciones podían resultar ininteligibles. O si coloca una coma en el lugar equivocado, la
capacidad de su programa de correo para procesar mensajes podría fallar. Cuando un encargado del correo
no podía analizar los encabezados enviados por otros, era como si a un empleado postal de Kenosha,
Wisconsin, le pidieran que entregara cartas con direcciones en sánscrito y árabe.
Las máquinas de ARPANET encontraban regularmente barreras de este tipo en el lenguaje

informático, y los problemas se multiplicaron con el crecimiento tanto del número de programas de
correo como del número de nodos en la Red. Dependiendo del tipo de sistema de correo que uno pueda usar
para enviar un mensaje, un programa o sistema operativo incompatible en el extremo receptor
“vomitaría” los encabezados, como lo expresó un observador. Si el mensaje llegó, es posible que la
persona que lo recibió aún tenga que lidiar con una traducción confusa o un formato incorrecto. Los
destinatarios se quejarían del remitente. Un remitente podría aceptar solucionar el problema con un truco
o una chapuza (“una chapuza es una tontería que funciona”, decía una definición), si tuviera tiempo. O, si
le gustaba bastante su propio programa de correo, podría simplemente quejarse del del destinatario.
Establecer un intercambio de correo electrónico era como invitar a alguien a salir. "El correo electrónico era
visto como algo entre adultos que consentían", dijo Brian Reid, un científico informático que fue
trabajando en su doctorado. en CarnegieMellon. Se necesitaba una cierta comprensión madura.

"Tengo un programa de correo electrónico, quiero enviarte un correo y tú quieres recibirlo", continuó, "y
siempre y cuando estemos de acuerdo con el estándar, está bien". Muchos usuarios de las primeras máquinas
de fax pasaron por el mismo tipo de galimatías para asegurarse de que la máquina del remitente pudiera
comunicarse con la máquina de fax del destinatario.
El problema se produjo a gran escala entre máquinas Tenex y no Tenex.

Los programadores de algunos sitios que no pertenecen a Tenex, como aquellos que trabajan con máquinas
basadas en el sistema operativo Multics, continuaron introduciendo programas y características de correo
electrónico en la sintaxis de sus propios sistemas operativos y continuaron enviando sus mensajes a través de la
Red. Las máquinas Tenex, sin embargo, no podían manejar la sintaxis de otros formatos utilizados en algunos
sitios, por lo que nuevamente se producirían conflictos y confusión.
La diversidad de sistemas no estándar en la Red causó problemas incluso con algo aparentemente tan trivial
como el signo @ de Tomlinson. La disputa por el signo @ duró mucho tiempo y tuvo muchas partes. Hubo
desacuerdo sobre qué debería ir en el lado izquierdo del letrero y qué debería ir en el derecho. Pero antes de
eso, hubo un debate sobre si debería usarse como delimitador entre los nombres de usuario y de host en la
dirección.
La gente de Multics se opuso vehementemente cuando se utilizó por primera vez, y es comprensible.
Tomlinson, un hacker de Tenex, había elegido el signo @ sin darse cuenta, quizás, de que en el sistema Multics
era el carácter utilizado para enviar un comando de “eliminación de línea”. Cualquier usuario de Multics que
intentara enviar un correo a “Tomlinson@bbntenex” rápidamente se metería en problemas.
Los multics comenzarían a leer la dirección, encontrarían el signo @ y descartarían todo lo que se
había escrito anteriormente en la línea.
Ted Myer y Austin Henderson, del grupo BBN Tenex, decidieron intentar resolver uno de estos problemas de
compatibilidad, el problema del encabezado. En abril de 1975 publicaron una nueva lista de encabezados
"estándar". El documento, al que le dieron el título “Protocolo de transmisión de mensajes”, apareció
como RFC 680.
Pero el RFC 680 inmediatamente creó un escándalo entre aquellos que pensaban que el esfuerzo estaba
demasiado orientado a Tenex. Postel, guardián de los RFC, cuyas palabras tranquilas a menudo eran
definitivas, empuñó el mazo. RFC 680, dijo, era el estándar más estándar que jamás haya tenido el correo. "Es
bueno que muchos programas de lectura de correo acepten correo que no se ajusta al estándar", dijo, "pero
eso no justifica que los programas de envío de correo violen el estándar". Si el estándar es inadecuado, añadió,
cualquier propuesta para cambiarlo es bienvenida.
La pelea dejó en claro que los sitios Tenex, liderados por BBN, formaban una cultura dominante en la
red, mientras que los sitios "minoritarios", con sus diversos sistemas operativos, representaban un
contramovimiento potencialmente rebelde. Así se plantaron las raíces de un conflicto prolongado que
continuó durante la década siguiente y que llegó a ser conocido en la comunidad como las guerras de
cabecera. Muchas de esas batallas se libraron en el ámbito de un nuevo grupo de conversadores
informáticos: el "Grupo Msg".
El grupo de mensajes
El 7 de junio de 1975, Steve Walker, director del programa ARPA en IPTO, redactó un mensaje para anunciar la
formación de algo nuevo: un grupo de discusión electrónico. La comunidad de la red, escribió, necesita
“desarrollar un sentido de lo que es obligatorio, lo que es bueno y lo que no es deseable en los servicios de mensajes.
Hemos tenido mucha experiencia con muchos servicios y deberíamos poder ordenar nuestras opiniones al respecto.
Agradeció las opiniones de cualquiera que estuviera dispuesto a aportarlas e incluso proporcionó un poco de
financiación ARPA para lanzarlo. “Todo esto es un nuevo intento”, continuó. “Espero que a partir de todo esto se pueda
desarrollar una estrategia a largo plazo sobre dónde deberían ir los servicios de mensajes en ARPANET y, de
hecho, en el DOD. Vamos a hacerlo”.
En el estilo verbal truncado que impregna la cultura informática, el Grupo de Servicios de Mensajes recibió el nombre
de MsgGroup.
Dave Farber de UC Irvine se ofreció como voluntario para ser el archivero de MsgGroup; y Farber ofreció la
ayuda de un colega, un consultor llamado Einar Stefferud. En poco tiempo, la mayor parte de las tareas domésticas
diarias recayó en Stefferud, quien comenzó en el trabajo manteniendo la lista de participantes de MsgGroup,
inscribiendo a los recién llegados, engatusándolos para que publicaran biografías introductorias de sí mismos y
resolviendo el correo devuelto. Stefferud se convertiría en el moderador del MsgGroup y en el hombre detrás de la
cortina. Actuando como intermediario, recibía mensajes para publicar y los enviaba manualmente a todos los
de la lista. Fue un proceso arduo que luego se automatizó.
No todo el mundo hacía sus negocios en el mercado al aire libre del grupo Msg; había tanto o más tráfico de correo
electrónico privado entre los programadores. Pero todos los involucrados en la implementación de sistemas de
correo en el mundo eventualmente participaron o al menos supieron lo que sucedió en el grupo. La discusión iba a
durar diez años. Con el tiempo, los aproximadamente cien participantes del MsgGroup intercambiaron miles de
mensajes y cientos de miles de palabras.
MsgGroup estuvo entre las primeras listas de correo de la red. Había otras listas de correo, la mayoría de ellas no
autorizadas, alrededor de los sitios educativos. La primera lista no oficial muy popular, llamada SFLovers,
estaba dedicada a los fanáticos de la ciencia ficción.
Las guerras de encabezados sacaron a relucir los rasgos obstinados y tenaces de los programadores.
Los conflictos operativos entre máquinas eran sólo la mitad. Los problemas con los encabezados también se debían al
desacuerdo humano sobre cuánta y qué tipo de información debería presentarse en la parte superior de los
mensajes. Las personas diferían mucho en cuanto a la cantidad de información del encabezado que les importaba
tratar cuando miraban su correo.
Algunos programadores y programas de correo incluían mucho más en sus campos de encabezado que otros.
Hicieron el pastel con recuentos de caracteres, palabras clave y varios temas esotéricos.
Mientras tanto, los críticos defendieron enérgicamente la economía y se opusieron a una sobrecarga de información.
Vieron demasiados encabezados gordos y frívolos: el equivalente electrónico de anotar el contenido de un trapo
de algodón en una hoja de papel. Los mensajes cortos con encabezados engorrosos siempre aparecían muy
pesados, desequilibrados, enfatizando el encabezado en lugar del mensaje. Brian Reid de CarnegieMellon,
que a menudo hacía sonar la voz de la razón en el
MsgGroup, estaba en el campo de los encabezados cortos. Un día recibió un mensaje sarcástico de un colega y lo
publicó en MsgGroup:
Fecha: 7 de abril de 1977 1712EST
De: Bob Chansler en CMU10A
Responder a: Cooperativa de queso en CMU10A
Asunto: Re: Cerca, pero sin cigarro
Para: BRIAN. REID en CMU10A
CC: Chansler@CMU10A
Remitente: BOB.CHANSLER en CMU10A
ID de mensaje: [CMU10A] 7 de abril de 1977 17:12:49 Bob Chansler en respuesta
Para: Su mensaje del 6 de abril de 1977
Misec#: 39492094
AñoSeq#: 4992488
Clase A
Subclase: MCMXLVII
Autor: RC12
Mecanógrafo: Fred
Terminal: TTY88
FEL#: 44
Razón: ¿Godzilla necesitaba una razón?
Válido: no antes del 12 de abril de 1977 1321Z
Suspender: después del 19 de abril de 1977 a las 00:00 horas
Erroresdeortografíaenestemensaje: 0
Errores ortográficos hasta la fecha: 23
Clima: Lluvia ligera, niebla
Pronóstico: Despejado por la mañana

Evaluación psicológica del remitente: Ligeramente inestable
Nivel de seguridad: Público
Subnivel de seguridad: 0
Autoridad para enviar: General
Autoridad a rcv: General
#personasenlasaladelaterminal: 12
XGP: el cortador hacia arriba no funciona
Alt/Pesoremitente: 76/205
Máquinas: M&M disponibles pero la máquina de almendras está vacía
M&MsÚltimo níquel: 17
HDRchksum: 032114567101

Brian,
No entiendo tu preocupación por el tamaño.

de encabezados de mensajes.
Beto.
¿Por qué no podemos configurar encabezados para imprimir solo las partes del encabezado que elegimos leer?
Preguntó Reid. "Continúe y coloque treinta y cuatro campos de encabezado diferentes", dijo. “Lo único que
realmente quiero ver es 'de' y 'fecha'”. Otros estuvieron de acuerdo. El programa ideal permitiría a los usuarios diseñar
sus propios encabezados. Al menos un elaborado sistema de correo, el NLS JOURNAL MAIL de
Doug Engelbart, ofrecía una característica de “información invisible” que permitía la visualización selectiva
de una gran cantidad de datos de encabezado.
El 12 de mayo de 1977, Ken Pogran, John Vittal, Dave Crocker y Austin Henderson lanzaron un golpe de
estado por correo informático. Anunciaron “por fin” la finalización de un nuevo estándar de correo, RFC 724, “Un
estándar oficial propuesto para el formato de mensajes de la red ARPA”. El estándar que proponían contenía
más de veinte páginas de especificaciones: formalidades sintácticas, semánticas y léxicas. El RFC explicó
que el receptor de un mensaje podría ejercer un extraordinario control sobre la apariencia del mensaje, dependiendo
de las capacidades de su sistema de lectura de correo.
En los días posteriores a la publicación del RFC 724, la respuesta de la comunidad informática fue, en el mejor de los
casos, fría al nuevo protocolo. Alex McKenzie de BBN fue particularmente franco. Postel,
quien había sido defensor del antiguo RFC 680, fue el menos impresionado por la nueva propuesta. Fue muy
duro con la afirmación de que este iba a ser un estándar ARPA oficial. "Hasta donde yo sé, ningún protocolo
ARPANET de ningún nivel ha sido sellado como oficial por ARPA", dijo. “¿Quiénes son los funcionarios de todos
modos? ¿Por qué este conjunto de organizaciones de investigación informática debería recibir órdenes de alguien? Se
puso demasiado énfasis en el oficialismo y no lo suficiente en la cooperación y el perfeccionamiento del sistema.
“Prefiero ver la situación como una especie de evolución paso a paso”, dijo, “donde documentos como los RFC 561,
680 y 724 registran los pasos. Hacer un gran comentario oficial sobre un paso puede hacer que sea muy
difícil dar el siguiente”.
El equipo de RFC 724 absorbió las críticas. Seis meses después, bajo el liderazgo de Dave Crocker y JohnVittal, se
publicó una edición final revisada del RFC 724 como RFC 733.
Esta especificación estaba pensada "estrictamente como una definición" de lo que se debía pasar entre los
hosts de ARPANET. No tenían la intención de dictar la apariencia de los programas de mensajes o las funciones
que podrían admitir. Dijeron que se requería menos de lo permitido por la norma, así que aquí estaba. Y allí
quedó.
Varios desarrolladores escribieron o revisaron programas de correo para cumplir con las nuevas pautas, pero
un año después de la publicación del RFC 733, el conflicto persistente se reanudó. De particular preocupación, los
encabezados RFC 733 eran incompatibles con un programa de correo llamado MSG (a pesar de que su autor, John
Vittal, había ayudado a escribir el RFC 733). MSG era de lejos el programa de correo más popular en
ARPANET.
Vittal, un hacker de hacker, había escrito el programa MSG en 1975 por puro amor al trabajo. MSG nunca recibió
financiación ni apoyo formal, “aparte de mí en mi tiempo libre”, explicó. Pero pronto, MSG tuvo una comunidad de usuarios
de más de mil personas, lo que en aquellos días significaba una gran porción del mundo conectado. Vittal había
usado el programa RDmail de Roberts, que era excelente para manejar dos o tres mensajes a la vez, o
incluso una pila de mensajes corta, pero ahora Vittal recibía veinte mensajes al día y quería un programa para
administrarlos con mayor facilidad. "Lo que MSG hizo fue cerrar el círculo", dijo, "de modo que se podían dividir los
mensajes en varios otros archivos, llamados carpetas y, en última instancia, responder y reenviar".
De hecho, Vittal se hizo ampliamente conocido por incluir la palabra "respuesta" en el léxico del correo electrónico.
Inventó el comando RESPUESTA, que hizo que responder mensajes fuera muy fácil.
Vittal recordó: “Estaba pensando: 'Oye, con un comando de respuesta no tengo que volver a escribir...
¡o escriba mal!: una dirección o direcciones del remitente”.
MSG, un modelo inspirador, generó toda una nueva generación de sistemas de correo, incluidos MH,
MM, MS, y un proyecto de BBN fuertemente financiado y patrocinado por el Pentágono llamado HERMES. MSG
fue la "aplicación asesina" original, una aplicación de software que arrasó en el mundo. Aunque nunca hubo nada oficial
al respecto, el GMS claramente contó con el más amplio apoyo popular. Estaba en toda la red; Incluso los altos
funcionarios de ARPA en el Pentágono lo utilizaron. Si algo fue el estándar más aceptado fue el glutamato monosódico,
que reinó durante mucho tiempo. (Algunas personas en BBN todavía usaban MSG en la década de 1990).
El MSG de Vittal y su comando ANSWER lo convirtieron en una figura legendaria en los círculos del correo electrónico.
"Fue gracias a Vittal que todos asimilamos el correo de la red en nuestra médula espinal".
recordó Brian Reid. “Cuando lo conocí años después, recuerdo que me sentí decepcionado (como
suele ocurrir cuando uno se encuentra con una leyenda viviente) al ver que tenía dos brazos y dos
piernas y ningún cohete en la espalda”.
Más que un simple gran truco, MSG fue la mejor prueba hasta la fecha de que en ARPANET se
podían crear reglas, pero ciertamente no prevalecieron. Las proclamaciones de oficialidad no
hicieron avanzar a la Red tanto como arrojar tecnología a la Red para ver qué funcionaba. Y
cuando algo funcionó, se adoptó.
Aventura y Quasar: la red abierta y la

libertad de expresión
Cuanto más utilizaba la gente ARPANET para el correo electrónico, más relajada se volvía respecto
de lo que decía. Hubo mensajes contra la guerra y, durante el apogeo de la crisis de Watergate,
un estudiante en ARPANET abogó por el juicio político a Nixon.
La red no sólo se estaba expandiendo, sino que se estaba abriendo a nuevos usos y creando nuevas
conexiones entre las personas. Y eso fue puro Licklider. Uno de los ejemplos más
impresionantes de esto comenzó con uno de los chicos IMP originales: Will Crowther.
Un pequeño círculo de amigos en BBN se había enganchado a Dungeons and Dragons, un

elaborado juego de rol de fantasía en el que un jugador inventa un escenario y lo puebla con monstruos
y rompecabezas, y los otros jugadores luego se abren camino a través de ese escenario.
Todo el juego existe sólo en el papel y en la mente de los jugadores.
Dave Walden conoció el juego una noche de 1975, cuando Eric Roberts, un estudiante de una clase
que daba en Harvard, lo llevó a una sesión de D&D. Walden inmediatamente reunió a un grupo de
amigos del equipo ARPANET para continuar con las sesiones. Roberts creó Mirkwood Tales,
una versión elaborada de Dragones y Mazmorras ambientada en la Tierra Media de JRR Tolkien.
El juego se prolongó durante la mayor parte de un año y se jugó principalmente en el piso de la sala
de Walden. Uno de los habituales era Will Crowther. Mientras que la otra docena de jugadores
eligieron nombres como Zandar, Klarf o Groan para sus personajes, el de Crowther era simplemente
Willie, un ladrón sigiloso.
Crowther también fue un apasionado explorador de cuevas. Y su esposa Pat había alcanzado renombre
entre los espeleólogos por haber formado parte de un pequeño grupo que descubrió el primer vínculo
conocido entre las cuevas Mammoth y Flint Ridge en Kentucky. El sistema combinado de 144 millas
era la cueva más larga conocida en el mundo. Crowther fue el cartógrafo de la Cave Research
Foundation. Utilizó sus horas libres para trazar intrincados mapas subterráneos en una computadora
BBN.
A principios de 1976, Will y Pat se divorciaron. Buscando algo que pudiera hacer con sus dos
hijos, se le ocurrió una idea que unía a Will el programador con Willie el ladrón imaginario: una
versión informática simplificada de Dragones y Mazmorras llamada Aventura.
Aunque el juego no utilizó mapas reales de las cuevas de Kentucky, Crowther basó la geometría de
Adventure en crudas imágenes mentales de esas cámaras subterráneas. El hierro
La rejilla por la que pasaban los jugadores al comienzo del juego se inspiró en las instaladas por el
Servicio de Parques en las entradas al sistema Flint Ridge. Incluso incluyó una o dos bromas internas
sobre espeleología; El "Y2" inscrito en una roca en un momento del juego es una abreviatura de
espeleólogo para una entrada secundaria.
Crowther terminó el programa en el transcurso de tres o cuatro fines de semana. A sus hijos, de siete y cinco
años, les encantó y Crowther comenzó a mostrárselo a sus amigos. Pero la ruptura de su matrimonio había
minado el espíritu de Crowther y nunca logró perfeccionar el juego.
Bob Taylor, ahora director del Laboratorio de Ciencias de la Computación del Centro de Investigación de
Palo Alto de Xerox Corporation, convenció primero a Severo Ornstein, luego a Will Crowther, para que se
unieran a él, y cuando Crowther se mudó a California en 1976 dejó el programa Adventure en un archivo
en un Computadora BBN. Aunque el juego estaba sin pulir, la noticia de la aventura se había filtrado
a través de la comunidad de la red.
Un estudiante de posgrado de Stanford llamado Don Woods se enteró de Adventure a través de un

amigo que había encontrado una copia en la computadora de la Escuela de Medicina de Stanford y descargó
el juego desde allí. Pero Woods tuvo dificultades para ejecutar Adventure al principio, y cuando lo hizo,
lo encontró plagado de errores. Aun así, estaba enganchado. "La aventura hizo que los usuarios sintieran
que estaban interactuando más con la computadora", dijo Woods. “Parecía responder más a lo que
escribías, en lugar de simplemente hacer sus propios movimientos como un oponente silencioso. Creo
que esto atrajo a muchos jugadores que, de otro modo, se habrían desanimado ante la idea de jugar "contra"
una computadora. Esto era jugar 'con' una computadora”.
El juego incluía a Will Crowther como autor, y Woods decidió localizar a Crowther para obtener el código
fuente y poder comenzar a reparar el pequeño programa rudimentario.
Envió correos electrónicos a todos los servidores de la red buscando a Crowther y finalmente lo encontró
en PARC. Crowther felizmente le entregó el código. Fueron necesarios varios meses para reelaborarlo,
durante los cuales el sencillo programa duplicó su tamaño. Woods creó nuevos obstáculos, añadió un pirata,
retorció aún más los laberintos y añadió varios tesoros que requirieron resolver algunos problemas antes de
ser encontrados.
Cuando terminó Adventure, Woods creó una cuenta de invitado en la computadora del Laboratorio
de Inteligencia Artificial de Stanford para permitir que la gente jugara, y enjambres de invitados iniciaron
sesión. Adventure se difundió como hula hula a medida que las personas se enviaban el programa entre
sí a través de la red. Como Crowther lo había escrito en FORTRAN, podía adaptarse a muchas
computadoras diferentes con relativa facilidad. Tanto Crowther como Woods alentaron a los
programadores a piratear el juego e incluyeron sus direcciones de correo electrónico para cualquiera que
buscara ayuda para instalar, jugar o copiar el juego.
La gente se quedó con los ojos llorosos buscando tesoros hasta altas horas de la madrugada. "Hace mucho
tiempo que perdí la cuenta de los programadores que me dijeron que la experiencia que los hizo comenzar a
usar computadoras fue jugar Adventure", dijo Woods. El juego inspiró cientos de imitaciones, que
eventualmente generaron toda una industria.
La aventura demostró el atractivo de una cultura de networking abierta. Y el énfasis en la apertura creció
con el tiempo. Había pocas puertas cerradas en la red y prevalecía un espíritu libre en las actitudes de la
gente sobre quién podía entrar y salir a través de ellas y para qué.
propósitos. Cualquiera que intentara restringir el uso libre de la red por parte de la población de estudiantes de
posgrado habría malinterpretado gravemente la mentalidad de la comunidad informática. ARPANET era
propiedad oficial del gobierno federal, pero el correo de la red se utilizaba para todo tipo de conversaciones
diarias.
Luego, en la primavera de 1977, Quasar entró por la puerta. Su llegada marcó el comienzo del primer debate sobre
la libertad de expresión en el ciberespacio. La controversia se centró en un dispositivo inusual fabricado por
Quasar Industries y estalló en una discusión sobre el uso de ARPANET, financiado por los contribuyentes, para
hablar, en términos abiertamente críticos, sobre una empresa privada.
El dispositivo, una creación de Quasar Industries, medía cinco pies y cuatro pulgadas y pesaba doscientas
cuarenta libras. Se llamaba robot doméstico Android y era un ayudante programable que podía realizar una
docena de tareas domésticas básicas, como fregar el suelo, cortar el césped, lavar platos y servir cócteles.
Venía dotado de personalidad y habla, para poder “interactuar en cualquier situación humana”. Podría
“enseñar francés a los niños” y “seguir enseñándoles mientras duermen”. Al precio anunciado de 4.000 dólares,
la cosa parecía una ganga.
Phil Karlton de CarnegieMellon fue el primero en alertar al MsgGroup, el 26 de mayo de 1977.

Su sitio en ARPANET estaba muy involucrado en la exploración de la inteligencia artificial, el reconocimiento de
voz y problemas de investigación relacionados, por lo que sabía un par de cosas sobre robots. El androide y su
inventor habían atraído bastante atención de la prensa nacional, la mayoría favorable. El argumento de venta de
Quasar también había llamado la atención de Consumer Reports, que publicó un artículo escéptico al respecto
en la edición de junio, recién publicada.
Al principio, Quasar no parecía más que una divertida distracción del negocio principal del MsgGroup. Todos
en el grupo sabían que se trataba de un engaño y, durante un tiempo, eso pareció suficiente. Pero entonces
surgió un sentimiento de deber cívico. Dave Farber contó que estaba en Boca Ratón, Florida, y escuchó en la
radio que el departamento de policía del condado de Dade estaba considerando comprar un robot
guardia Quasar para la cárcel de su condado, por 7.000 dólares. En marzo , el Boston Globe publicó un artículo
citando a Marvin Minsky del MIT y otros expertos escépticos en IA.
Pero el artículo adoptó la actitud general, dijo un miembro de MsgGroup, de que “sólo sirve para demostrarles
que esos académicos no pueden hacer nada práctico, y todo lo que necesitan es un tipo que trabaje en la parte
trasera de un garaje para avergonzarlos”. .” La saga dejó un rastro de incredulidad en la comunidad de investigación
en inteligencia artificial.
Brian Reid y un colega, Mark Fox, del Laboratorio de Inteligencia Artificial CarnegieMellon, publicaron un informe
poco convencional para todos los miembros del MsgGroup, brindándoles un relato personal de su
inspección del robot doméstico, "Sam Strugglegear", en un departamento grande. tienda en el centro
de Pittsburgh. La gente de la comunidad de investigación, conociendo el trabajo pionero de IA de CMU, había
estado llamando al laboratorio para preguntar cómo era posible que el robot de Quasar fuera mucho mejor
en reconocimiento de voz que cualquier cosa que CMU hubiera producido. A la altura del desafío, un
equipo de cuatro miembros de CMU realizó el trabajo de campo.
"Encontraron un espectáculo aterrador", informaron Reid y Fox. En el departamento de hombres, entre

los trajes de tres piezas, había una “lata de aerosol sobre ruedas” de cinco pies y dos pulgadas que hablaba
animadamente ante una multitud. Motores eléctricos y un sistema de engranajes movían los brazos del dispositivo.
El robot parecía versado en cualquier tema, reconocía las características físicas de los clientes y se movía
libremente en cualquier dirección. La multitud quedó encantada.
Pero los científicos se mostraron escépticos. Miraron a su alrededor en busca de alguna evidencia de un control
remoto. “He aquí, a unos tres metros del robot, de pie entre la multitud, encontramos a un hombre con un traje azul con
la mano en la boca contemplativamente, como Aristóteles contemplando el busto de Homero en el famoso
cuadro de Rembrandt”. Reid y los demás observaron durante un rato y notaron que cada vez que el robot hablaba,
también lo hacía el hombre del traje azul, murmurando en su mano. El hombre tenía un alambre colgando
sospechosamente de su cintura.
La discusión sobre el robot Quasar continuó intermitentemente durante un par de años hasta que, a principios de 1979,
Einar Stefferud, el moderador del MsgGroup, y Dave Farber, que había estado al margen del comentario, enviaron una
nota de precaución al MsgGroup. . “Estamos pidiendo problemas potenciales”, advirtieron, “cuando criticamos al robot
Quasar”.
Utilizar las instalaciones del gobierno de Estados Unidos para difamar a una corporación, dijeron, podría resultar
contraproducente para la comunidad de investigación de ARPA. Instaron a sus pares a imponerse una cuidadosa
autocensura y a informar sólo de hechos de interés técnico para la comunidad. No todos estuvieron de acuerdo, y con
eso el MsgGroup se vio envuelto en un intercambio de introspección.
John McCarthy, que trabajó en el Laboratorio de Inteligencia Artificial de Stanford, fue uno de los más ofendidos por
las afirmaciones de Quasar. Le dijo al grupo que no se dejaría disuadir por la especulación de que Quasar podría
presentar una demanda. "Creo que alguien parece tener miedo de su sombra", dijo McCarthy. "Nunca ha sido
costumbre de los vendedores de aceite de serpiente de carnaval demandar a sus críticos". Minsky y Reid también
dejaron claro que le dirían a cualquier periodista que les preguntara que creían que el robot era una broma, y ya
habían expresado esa opinión a más de una docena de periodistas.
“No tengo miedo de que me demanden”, respondió Farber. “Sin embargo, estamos utilizando un vehículo público
llamado ARPANET. De este modo exponemos a ARPA, DOD y nuestro futuro acceso y uso de la red a ciertos peligros
cuando utilizamos ese vehículo para material potencialmente difamatorio”.
Farber volvió a instar a la moderación.
Reid intervino y dijo: "[el] MsgGroup es lo más cercano que tenemos a un foro comunitario de informática a nivel
nacional". Reid había comenzado a notar que el Grupo de Mensajes era como un club social. Habían discutido tanto
entre ellos que se habían hecho amigos. Restringir la discusión sería antinatural. Además, Reid adoptó una visión
más liberal de la libertad de expresión y razonó que el experimento en comunicaciones se vería afectado si se
restringieran los temas. "Hasta que la gente empiece a sugerir el derrocamiento de nuestro gobierno", dijo, "no creo
que ningún tema sensato deba quedar fuera de los límites".
Alguien sugirió adjuntar un descargo de responsabilidad a las comunicaciones personales en

ARPANET para que las opiniones personales no se confundan con asuntos oficiales.
Alguien más admitió: “¿Quién no ha utilizado Net mail para comunicarse personalmente? ¿Quién no ha pasado algún
tiempo jugando a algún juego nuevo en la Red? Se honesto." La pasión en defensa de la libertad de expresión
fue acompañada por una voluntad igualmente fuerte de autoprotección; la forma de proteger la red en sí era no atraer
una supervisión no deseada por parte del gobierno.
Después de unos días, la discusión se agotó sin resolución y el MsgGroup continuó con sus actividades como
de costumbre.
Lo que surgió del debate fue una fuerte evidencia de que la comunidad de redes sentía un profundo interés en la
creación de la Red, con o sin financiación ARPA, y estaba tratando celosamente de proteger su derecho a determinar
su futuro. En un ámbito donde, en cierto sentido, la identidad personal se define enteramente por las palabras que
la gente elige, la libertad de expresión parecía superada sólo por la preocupación por la supervivencia del ámbito
mismo.
Umbilicales de cobre
Durante el primer trimestre de 1976, los informes de tráfico mostraban que el volumen de correo de ARPANET,
comparado con el volumen del correo regular estadounidense, era un simple rastro de hormigas tras las huellas
de una manada de elefantes. El Laboratorio de Inteligencia Artificial del MIT, por ejemplo, pasó unos 9.925
mensajes durante el período. (En 1996, en comparación, algunos sitios procesaban 150.000 mensajes de
correo electrónico cada día.) El MIT era un sitio típico y, por extrapolación, si una máquina procesaba alrededor de
cien mensajes de correo electrónico al día, multiplicados por un factor de Aproximadamente 98 (el número de
servidores que había entonces en la Red) de correo electrónico todavía no parecían representar una amenaza para
el sistema postal de Estados Unidos. La oficina de correos maneja más de 50 mil millones de envíos de correo
de primera clase al año. Pero la pronunciada curva de crecimiento del correo electrónico no pasaba desapercibida.
En el sector privado, las empresas estaban preparadas para que despegara el concepto del servicio de correo
electrónico. La Computer Corporation of America pronto comenzó a vender uno de los primeros paquetes de
software de correo electrónico disponibles comercialmente, un producto de 40.000 dólares llamado COMET,
diseñado para la minicomputadora PDP11. Otro programa llamado MESSENGER, desarrollado para
computadoras IBM 360 y 370, pronto estuvo disponible en una compañía llamada OnLine Software International,
por 18.000 dólares. Los costos estaban bajando y algunos analistas proyectaron un impacto “devastador” en
el negocio de primera clase del Servicio Postal de Estados Unidos.
“Estamos siendo ignorados tecnológicamente”, informó un asistente del director general de correos de los EE.UU. a
principios de 1976. La tendencia de crecimiento de la nueva tecnología y su evidente potencial eran, en efecto,
bastante dramáticos. Algunas versiones de los programas de correo ARPANET más sofisticados, como MSG, HERMES
y NLS JOURNAL MAIL de SRI, estaban llegando a manos de no investigadores. Varias organizaciones importantes,
entre ellas el Servicio Geológico de Estados Unidos, el Departamento de Comercio, la Agencia de Seguridad
Nacional y Gulf Oil, habían comenzado a utilizar el correo electrónico a través de redes de área local.
El gobierno estaba mirando de cerca el futuro del servicio de correo electrónico. Un informe para la Oficina de
Política de Telecomunicaciones de la Casa Blanca elaborado por la consultora Arthur D.
Little estimó que el 30 por ciento de todo el correo de primera clase probablemente se enviaría electrónicamente
dentro de unos pocos años. El servicio postal reaccionó a esa predicción adjudicando a RCA un contrato de 2,2
millones de dólares para evaluar la viabilidad técnica y económica de proporcionar un servicio de correo
electrónico. En su informe, RCA abogó por añadir el correo electrónico a los servicios de la oficina de correos. Un
panel asesor del USPS también examinó de cerca. Recomendaron hacer un “compromiso firme y continuo” con el
correo electrónico, a la par del programa espacial tripulado de la NASA.
La campaña presidencial de Jimmy Carter utilizó el correo electrónico varias veces al día en el otoño de
1976. El sistema que utilizaban era un programa básico de buzón de correo, una tecnología que ya tenía
más de una década de existencia. Pero para una campaña política esto fue un golpe revolucionario en
las comunicaciones. Sobre esa base, Carter fue etiquetado como el “candidato impulsado por computadora”.
En 1979, el presidente Carter apoyaba una propuesta de la oficina de correos para ofrecer un tipo limitado de
servicio de mensajes electrónicos a la nación. El esquema híbrido funcionó más como un servicio de
telegramas que como un sistema de comunicaciones electrónicas de última generación. Los mensajes
se transmitirían electrónicamente entre oficinas de correos durante la noche y luego se
entregarían en la puerta de los destinatarios al día siguiente. La propuesta destacó principalmente por lo
cautelosa que parecía en vista de las posibilidades tecnológicas.
Stefferud y otros miembros del MsgGroup, la comunidad con mayor experiencia con el correo electrónico,
vieron de inmediato las fallas en el plan del Servicio Postal de EE. UU., que implicaba convertir
mensajes de medios electrónicos digitales a papel y luego entregarlos en mano como lo haría con el correo
ordinario. . Este enfoque no sólo costaría más que el correo electrónico, sino que nunca sería lo
suficientemente rápido para competir con el correo electrónico mientras dependiera de la fuerza
tradicional del USPS para esos pasos finales hasta el buzón. Las computadoras de escritorio “serán el
buzón de correo perfecto”, predijo Stefferud, y evitarían por completo la oficina de correos. Se podría
establecer una analogía con la noción alguna vez ridícula de recolección automatizada de basura, que
era impensable hasta la invención del "cerdo eléctrico", el primer nombre que se le dio al triturador de basura
en el fregadero. “La clave no está en automatizar el mecanismo bolsa/lata/camión/persona”, afirmó
Stefferud. "Se trata de evitarlos por completo".
El USPS, como antes AT&T, nunca se liberó realmente de la mentalidad que protegía su negocio
tradicional, probablemente porque ambas eran entidades monopolísticas. Al final, el Departamento de
Justicia de Estados Unidos, la FCC e incluso la Comisión de Tarifas Postales se opusieron a cualquier
papel importante del gobierno en los servicios de correo electrónico, prefiriendo dejarlos en manos del libre mercado.
Ningún tema fue nunca demasiado pequeño para una larga discusión en el Grupo de Mensajes. La velocidad
y facilidad del medio abrieron perspectivas de conversación informal y espontánea. A finales de la década,
personas como Licklider y Baran se dieron cuenta de que una revolución que ellos habían ayudado a
iniciar estaba en marcha.
"Mañana, los sistemas de comunicación por computadora serán la regla para la colaboración remota" entre
autores, escribieron Baran y Dave Farber de UC Irvine. Los comentarios aparecieron en un artículo escrito
conjuntamente, mediante correo electrónico, con quinientas millas de distancia entre ellos. Fue
“publicado” electrónicamente en MsgGroup en 1977. Y continuaron: “A medida que los sistemas de
comunicación por computadora se vuelvan más poderosos, más humanos, más indulgentes y, sobre todo,
más baratos, se volverán ubicuos”. Llegarían las reservas de hotel automatizadas, la verificación de crédito,
las transacciones financieras en tiempo real, el acceso a seguros y registros médicos, la
recuperación de información general y el control de inventario en tiempo real en las empresas.
A finales de la década de 1970, el informe final de la Oficina de Técnicas de Procesamiento de Información

a la dirección de ARPA sobre la finalización del programa de investigación ARPANET concluía de manera
similar: “La mayor sorpresa del programa ARPANET ha sido la increíble popularidad y el éxito del correo en
red. No hay duda de que las técnicas del correo en red
desarrollados en relación con el programa ARPANET van a recorrer el país y cambiarán drásticamente las
técnicas utilizadas para la intercomunicación en los sectores público y privado”.
Para los miembros del MsgGroup, el correo electrónico era tan fascinante como un diamante expuesto
a la luz. Los miembros de MsgGroup investigaron cada detalle. Eran adictos a la tecnología.
La cuestión de los sellos de fecha y hora, por ejemplo, era clásica. “El jefe del jefe de mi jefe se queja
de los desvaríos de los trasnochadores”, dijo alguien. "Él puede saber por la marca de tiempo (y los
hábitos del remitente) qué tan en serio debe tomarse el mensaje".
“Quizás deberíamos marcar la hora con la fase de la luna además de la fecha y la hora”, dijo otro. (Al poco
tiempo alguien escribió un programa de correo electrónico que hacía precisamente eso).
"Me gusta mucho ver una marca de tiempo precisa", dijo alguien más. "Es agradable poder desentrañar
la secuencia de comentarios recibidos en orden desordenado".
“Algunas personas lo utilizan descaradamente como una especie de superioridad. 'Trabajo más horas que
tú'”.
Los miembros de MsgGroup podrían discutir sobre cualquier tema. Había momentos en los que uno
juraba que acababa de visitar a un acalorado grupo de abogados, gramáticos o rabinos.
Los extraños caían casualmente en el diálogo o, como alguien lo llamó, el “polílogo”. A medida que los
clientes habituales se familiarizaron entre sí, se consolidaron rápidamente amistades, a veces años antes
de que la gente se conociera. En muchos sentidos, los valores básicos de la comunidad ARPANET eran
tradicionales: libertad de expresión, igualdad de acceso y privacidad personal. Sin embargo, el
correo electrónico también fue desinhibidor, creando puntos de referencia completamente propios, una
sociedad virtual, con modales, valores y comportamientos aceptables (la práctica de “flamear”, por ejemplo)
extraños para el resto del mundo.
La familiaridad en el MsgGroup en ocasiones engendró el lenguaje del desprecio. El primer verdadero

“incendio” (una forma de diálogo fogoso, a menudo abusivo) en ARPANET había estallado a mediados de
los años 1970. El medio engendró réplicas precipitadas y peleas verbales. Sin embargo, los intensos
incendios se mantuvieron relativamente bajo control en el Grupo Msg, que se consideraba civilizado.
Stefferud mantuvo unido al grupo casi solo y con serenidad cuando las cosas se pusieron
especialmente estridentes y conflictivas. Se esforzó por mantener el MsgGroup funcionando,
analizando encabezados difíciles cuando era necesario o suavizando malentendidos, asegurándose de
que el estado de ánimo del grupo y su tráfico nunca se volvieran demasiado complicados. Lo peor que
alguna vez dijo, cuando estuvo acosado por problemas técnicos, fue que algunos cabezazos tenían “mal aliento”.
En comparación, había un grupo de discusión al lado (metafóricamente hablando), llamado Header People,
que tenía fama de ser un infierno. "Normalmente usamos ropa interior de amianto", dijo un participante.
Con sede en el MIT, Ken Harrenstien había fundado Header People en 1976. El grupo no era oficial,
pero lo más importante era que no estaba moderado (lo que significa que no tenía un filtro humano como
el de Stefferud). Harrenstien se había propuesto reclutar al menos un desarrollador de cada tipo de
sistema en ARPANET, y en poco tiempo los conflictos en Header People elevaron el debate sobre
los encabezados al nivel de una guerra santa antes de estallar. "Un grupo de toleteros enérgicos", dijo
Harrenstien, "haciendo añicos un cadáver equino". Los dos grupos orientados al correo se
superpusieron considerablemente; incluso en civilizado
En la empresa MsgGroup, los ánimos estallaban periódicamente. Los ataques ácidos y el nivel
de arenga exclusivo de la comunicación en línea, inaceptablemente asocial en cualquier otro contexto,
eran extrañamente normativos en ARPANET. Las llamas podrían encenderse en cualquier momento
sobre cualquier cosa y podrían durar un mensaje o cien.
La controversia FINGER, un debate sobre la privacidad en la Red, ocurrió a principios de 1979 e

involucró algunos de los peores enfrentamientos en la experiencia del Grupo Msg. La lucha fue por la
introducción, en CarnegieMellon, de un widget electrónico que permitía a los usuarios echar un vistazo
a los hábitos en línea de otros usuarios de la Red. El comando FINGER había sido creado a principios
de los años 1970 por un científico informático llamado Les Earnest en el Laboratorio de Inteligencia
Artificial de Stanford. “La gente generalmente trabajaba allí muchas horas, a menudo con horarios
impredecibles”, dijo Earnest. “Cuando querías reunirte con algún grupo, era importante saber quién
estaba allí y cuándo probablemente reaparecerían los demás. También era importante poder localizar a
posibles jugadores de voleibol cuando querías jugar, a los fanáticos de la comida china cuando querías
comer y a los usuarios de computadoras antisociales cuando parecía que algo extraño estaba
sucediendo en el sistema”. le permite leer los mensajes de otra persona, pero puede indicar la
fecha y hora del último inicio de sesión de la persona y cuándo fue la última vez que leyó el correo.
Algunas personas tuvieron un problema con eso.
En un esfuerzo por respetar la privacidad, Ivor Durham de CMU cambió la configuración predeterminada
de DEDO; añadió un par de bits que podían activarse o desactivarse, de modo que la información
pudiera ocultarse a menos que un usuario decidiera revelarla. Durham fue quemado sin piedad. Lo
llamaron de todo, desde cobarde hasta socialmente irresponsable, político mezquino y cosas
peores, pero no por proteger la privacidad. Fue criticado por jugar con la apertura de la red.
El debate comenzó como un diálogo interno en CMU, pero Dave Farber lo filtró a
ARPANET, quien quería ver qué pasaría si lo revelaba al mundo exterior. La consiguiente fiesta de
llamas consumió más de 400 mensajes.
En el apogeo del debate sobre FINGER, una persona abandonó el grupo de mensajes disgustada
por el incendio. Al igual que con el debate sobre Quasar, la controversia FINGER terminó sin
conclusiones. Pero ambos debates enseñaron a los usuarios mayores lecciones sobre el medio que
estaban utilizando. Algunos decían que la velocidad del correo electrónico fomentaba las llamas;
cualquiera podría disparar una réplica en el acto y sin el factor moderador de tener que mirar al objetivo a los ojos.
A finales de la década, el tono del MsgGroup, que había comenzado con rigidez, era el de una
expansiva batalla campal. Stefferud siempre intentaba que los recién llegados se presentaran
electrónicamente al unirse al grupo; al partir, algunos se despiden para volver a aparecer más tarde en
otros sitios; sólo una o dos personas se quejaron, bastante ceremoniosamente, de un festival de llamas
o de alguna otra indignidad percibida.
Uno de los eminentes estadistas del MsgGroup, Dave Crocker, a veces sondeaba la Red con la
curiosidad de un sociólogo. Un día, por ejemplo, envió una nota a aproximadamente 130 personas en
todo el país alrededor de las cinco de la tarde, sólo para ver qué tan rápido recibirían el mensaje y
responderían. Las estadísticas de respuesta, informó, fueron “un poco aterradoras”. Siete
personas respondieron en noventa minutos. En veinticuatro horas había recibido veintiocho respuestas.
Los tiempos de respuesta y los números en ese orden pueden parecer
apenas digno de mención en una cultura que desde entonces ha elevado al cuadrado y al cubo sus
expectativas sobre la velocidad, facilidad y alcance de la tecnología de la información. Pero en la década de
1970 “fue una experiencia absolutamente asombrosa”, dijo Crocker, haber recibido tantas respuestas,
con tanta rapidez y facilidad.
El 12 de abril de 1979, un recién llegado al MsgGroup llamado Kevin MacKenzie se angustiaba

abiertamente por la “pérdida de significado” en este medio electrónico encuadernado textualmente.
Sin duda, el correo electrónico permitía un intercambio verbal espontáneo, pero le preocupaba su
incapacidad para transmitir gestos humanos, expresiones faciales y tono de voz, todo lo cual surge
naturalmente al hablar y expresa todo un vocabulario de matices en el habla y el pensamiento. incluyendo
ironía y sarcasmo. Tal vez, dijo, podríamos ampliar el conjunto de puntuación en los mensajes de correo
electrónico. Para indicar que una oración en particular debe ser irónica, propuso insertar un guión y un
paréntesis al final de la oración, así: ).
MacKenzie confesó que la idea no era del todo suya; había sido provocado por algo que había leído sobre
un tema diferente en una copia antigua del Reader's Digest. Aproximadamente una hora más tarde, fue
quemado, o mejor dicho, chamuscado. Le dijeron que su sugerencia era “ingenua pero no estúpida”.
Le dieron una breve conferencia sobre el dominio del lenguaje por parte de Shakespeare sin notación auxiliar.
“Quienes no aprendan a utilizar bien este instrumento no podrán salvarse con un alfabeto ampliado; sólo
nos afligirán con un galimatías ampliado”. ¿Qué sabía Shakespeare? ;) Emoticonos y
emoticones :), enarbolados sin duda por el populacho, crecieron en el correo electrónico y se convirtieron
en la iconografía de nuestro tiempo.
Es un poco difícil precisar cuándo o por qué (tal vez fue el agotamiento, tal vez ahora había demasiados
músicos nuevos en el MsgGroup), pero a principios de la década de 1980, nota por nota, la orquesta que
había estado actuando magníficamente y que colectivamente había creado e mail a lo largo de una década,
empezó a abandonar la partitura, casi imperceptiblemente al principio. Una voz clave se desvanecería
aquí, otra se desvanecería allí. En lugar de acordes, el ruido blanco pareció superar gradualmente al
MsgGroup.
En cierto sentido, no importaba. El diálogo mismo en el Grupo de Mensajes siempre había sido más
importante que los resultados. Crear los mecanismos del correo electrónico fue importante, por supuesto,
pero MsgGroup también creó algo completamente distinto: una comunidad de iguales, muchos de los cuales
nunca se habían conocido y que se comportaban como si se conocieran de toda la vida. Era el primer
lugar donde encontraron algo que habían estado buscando desde que surgió ARPANET. MsgGroup fue
quizás la primera comunidad virtual.
El atractivo de la Red no surgió de cómo se construyó o cómo funcionó, sino de cómo se utilizó. En 1980, la
Red era mucho más que una colección de ordenadores y líneas alquiladas.
Era un lugar para compartir trabajo y construir amistades y un método de comunicación más
abierto. El romance de Estados Unidos con el sistema de autopistas, por analogía, no fue creado tanto por
la primera persona que descubrió cómo nivelar una carretera o hacer asfalto o pintar una franja en el medio,
sino por la primera persona que descubrió que se podía conducir un convertible. Ruta 66 como James
Dean y pon tu radio a todo volumen y pásalo genial.
8
Un cohete en nuestras manos
Bob Kahn dejó BBN y se puso a trabajar para Larry Roberts en 1972. Había aplazado su llegada a
Washington durante un año para quedarse en Cambridge y planificar la manifestación de la ICCC.
Después de haber pasado seis años ininterrumpidos centrado en las redes informáticas, ahora estaba listo
para hacer un rompimiento definitivo. No quería ejecutar un proyecto de red. Así que él y Roberts
acordaron que Kahn establecería un nuevo programa en técnicas de fabricación automatizadas.
Pero el Congreso canceló el proyecto antes de que llegara Kahn. A estas alturas, ARPA se había
cambiado a DARPA, la Agencia de Proyectos de Investigación Avanzada de Defensa. Como dijo una vez
Kahn, el D siempre había estado ahí, pero ahora ya no estaba en silencio. El nombre
ARPANET permaneció.
Una vez finalizado el proyecto de fabricación, Kahn fue llamado de nuevo al campo en el que se había vuelto
experto. Pero quería trabajar en los experimentos más nuevos.
Los primeros años de la década de 1970 fueron una época de intensa experimentación con las redes de
ordenadores. Algunas personas estaban empezando a pensar en nuevos tipos de redes de paquetes.
Era poco probable que los principios básicos de la conmutación de paquetes mejoraran dramáticamente. Y
los protocolos, interfaces y algoritmos de enrutamiento para manejar mensajes se estaban volviendo más
refinados. Sin embargo, un área aún por explorar era el medio a través del cual viajaban los datos.
La red de líneas telefónicas existente de AT&T había sido la primera opción obvia. Pero ¿por qué no crear
una red inalámbrica transmitiendo paquetes de datos “al aire” en forma de ondas de radio?
En 1969, antes de que Bob Taylor dejara ARPA, estableció la financiación para una red de radio fija
que se construiría en la Universidad de Hawaii. Fue diseñado por un profesor llamado Norm Abramson y
varios colegas. Construyeron un sistema simple utilizando radios para transmitir datos entre siete
computadoras ubicadas en cuatro islas.
Abramson lo llamó ALOHA.
El ALOHANET utilizaba radios pequeñas, idénticas a las utilizadas por los taxis, que compartían una
frecuencia común en lugar de canales separados. El sistema empleó un protocolo muy relajado.
La idea central era que cada terminal transmitiera cuando quisiera. Pero si los datos chocaran con la
transmisión de otra persona (lo que sucedía cuando había mucho tráfico), los receptores no podrían
decodificar ninguna de las transmisiones correctamente. Entonces, si la radio fuente no recibió confirmación,
asumió que el paquete se había confuso; retransmitió el paquete más tarde en un intervalo aleatorio. El
sistema ALOHA era como un servicio telefónico que te decía, después de intentar hablar, y no hasta
entonces, que la línea estaba ocupada.
A Roberts y Kahn les gustó la idea general de los enlaces de radio entre computadoras. ¿Por qué no hacer
algo aún más desafiante: idear pequeños “sitios” de computadoras portátiles transportados en vehículos o
incluso a mano, conectados entre sí en una red de conmutación de paquetes? En 1972, Roberts esbozó
el plan. Imaginó una red en la que un miniordenador central
situado en una potente estación de radio se comunicaría con sitios de ordenadores móviles más pequeños.
Roberts pidió al SRI que estudiara el problema y elaborara un sistema práctico.
El concepto de sitios de computadoras móviles tenía un atractivo evidente para el Ejército. Las
computadoras de campo de batalla instaladas en vehículos o aviones (objetivos en movimiento) serían
menos vulnerables y más útiles que las instalaciones fijas. Aún así, la destrucción del elemento más
crucial (la computadora maestra estacionaria en un sistema centralizado) eliminaría toda una red. La
necesidad de defenderse de ese peligro fue lo que llevó a Paul Baran a idear redes distribuidas en primer
lugar. Así pues, desde el punto de vista de la capacidad de supervivencia y el fácil despliegue, la red de radio
por paquetes se concibió como una versión inalámbrica de ARPANET, distribuida en lugar de
centralizada. A lo largo de los años, el programa de radio por paquetes se implementó en un puñado de
sitios militares, pero los problemas técnicos lo encarecieron y finalmente se eliminó gradualmente.
El alcance limitado de las señales de radio hizo necesario que las redes de radio por paquetes utilizaran
sitios de retransmisión a no más de unas pocas docenas de kilómetros de distancia. Pero un vínculo por
encima de la Tierra no tendría tales limitaciones. Un relevo de este tipo “vería” casi todo un hemisferio de la Tierra.
Mientras supervisaba los proyectos de radio por paquetes, Kahn comenzó a pensar en redes conectadas por
satélites accesibles en amplios dominios: hacia y desde barcos en el mar, estaciones terrestres remotas y
aviones que vuelan casi a cualquier parte del mundo.
A principios de la década de 1970, muchos satélites de comunicaciones (la mayoría de ellos militares)
estaban en órbita. Debidamente equipado, un satélite de este tipo podría servir como relevo para las comunicaciones.
Dadas las enormes distancias que implican las comunicaciones por satélite, las señales se retrasarían.
El viaje promedio de un paquete a su destino tomaría alrededor de un tercio de segundo, varias veces más
que los retrasos de host a host en ARPANET. Como resultado, las redes de paquetes por satélite serían
lentas.
Aún así, la idea de que las redes de conmutación de paquetes y sus computadoras conectadas pudieran
conectarse mediante ondas de radio rebotadas desde un satélite era atractiva, no sólo para el gobierno
estadounidense sino también para los europeos, porque los circuitos terrestres transatlánticos en ese
momento eran costosos y propensos a errores. . La red de satélites recibió el nombre de SATNET.
A los investigadores de Estados Unidos se unieron científicos informáticos británicos y noruegos, y en
poco tiempo también se establecieron enlaces por satélite con Italia y Alemania.
Durante un tiempo, a SATNET le fue bien. Sin embargo, con el tiempo, la compañía telefónica mejoró
sus líneas transatlánticas de cobre a cables de fibra óptica de alta velocidad, eliminando la necesidad del más
complicado SATNETlink.
Las lecciones técnicas de los experimentos de radio y satélites fueron menos significativas que las ideas
más amplias de creación de redes que inspiraron. Era obvio que habría más redes.
Varios gobiernos extranjeros estaban construyendo sistemas de datos y un número creciente de grandes
corporaciones estaban empezando a desarrollar sus propias ideas para establecer redes. Kahn
comenzó a preguntarse sobre la posibilidad de vincular las diferentes redes.
El problema se le ocurrió por primera vez mientras trabajaba en el proyecto de radio por paquetes en 1972.
"Mi primera pregunta fue: '¿Cómo voy a vincular este sistema de radio por paquetes a cualquier
recurso computacional de interés?'", dijo Kahn. “Bueno, mi respuesta fue: 'Vinculémoslo a
theARPANET', excepto que eran dos redes radicalmente diferentes en muchos sentidos”.
Al año siguiente, nació otro esfuerzo de ARPA, llamado Internetting Project.
En el momento de la manifestación de la ICCC en Washington en 1972, los líderes de varios

proyectos de redes nacionales habían formado un Grupo de Trabajo de Redes Internacionales
(INWG), con Vint Cerf a cargo. Los proyectos de redes de conmutación de paquetes en Francia
e Inglaterra estaban dando resultados favorables. El trabajo de Donald Davies en el Laboratorio
Nacional de Física del Reino Unido avanzaba espléndidamente. En Francia, un informático llamado
Louis Pouzin estaba construyendo Cyclades, una versión francesa de ARPANET. Tanto Pouzin
como Davies habían asistido a la manifestación de la ICCC en Washington. “El espíritu
después de ICCC”, dijo Alex McKenzie, representante de BBN ante el INWG, “fue: 'Hemos
demostrado que la conmutación de paquetes realmente funciona a nivel nacional.
Tomemos la iniciativa en la creación de una red internacional de redes'”.
Larry Roberts estaba entusiasmado con INWG porque quería extender el alcance de ARPANET
más allá del mundo financiado por DARPA. Los británicos y los franceses estaban igualmente
entusiasmados con la idea de ampliar el alcance de sus redes nacionales de investigación.
"El desarrollo de tecnología de interconexión de redes fue una manera de lograrlo", afirmó
McKenzie. El INWG comenzó a buscar lo que llamaron una “Red Concatenada”, o CATENET
para abreviar, una interconexión transparente de redes de tecnologías y velocidades
dispares.
Una Internet
La colaboración que Bob Kahn caracterizaría años más tarde como la más satisfactoria de su carrera
profesional tuvo lugar durante varios meses en 1973. Kahn y Vint Cerf se conocieron durante las
semanas de pruebas en la UCLA a principios de 1970, cuando habían obligado al recién nacido
ARPANET a entrar en catatonia. sobrecargando los IMP con tráfico de prueba. Siguieron siendo
colegas cercanos y ahora ambos estaban pensando detenidamente en lo que se necesitaría para
crear una conexión perfecta entre diferentes redes. “Por esta época”, recuerda Cerf, “Bob empezó a
decir: 'Mira, mi problema es cómo consigo que una computadora que está en una red satelital,
una computadora en una red de radio y una computadora en ARPANET se comuniquen
uniformemente entre sí sin darme cuenta de lo que está sucediendo. pasando en el medio?'”
Cerf estaba intrigado por el problema.
En algún momento de la primavera de 1973, Cerf estaba asistiendo a una conferencia en un hotel
de San Francisco, sentado en el vestíbulo esperando que comenzara una sesión, cuando empezó a
garabatear algunas ideas. Para entonces, él y Kahn habían estado hablando durante varios meses
sobre lo que se necesitaría para construir una red de redes, y ambos habían estado
intercambiando ideas con otros miembros del Grupo de Trabajo de Redes Internacionales. A Cerf y
Kahn se les ocurrió que lo que necesitaban era una "puerta de enlace", una computadora de
enrutamiento situada entre cada una de estas diversas redes para transferir mensajes de un sistema
a otro. Pero era más fácil decirlo que hacerlo. "Sabíamos que no podíamos cambiar ninguna de las
redes de paquetes", dijo Cerf. "Hicieron todo lo que hicieron porque estaban optimizados para ese
entorno". En lo que respecta a cada red, la puerta de enlace tenía que parecerse a un servidor normal y corriente.
Mientras esperaba en el vestíbulo, dibujó este diagrama:

Reproducción de las primeras ideas de diseño de Internet.
"Nuestra idea era que, claramente, cada puerta de enlace tenía que saber cómo comunicarse con
cada red a la que estaba conectado", dijo Cerf. “Supongamos que está conectando la red de radio
por paquetes con ARPANET. La máquina de puerta de enlace tiene un software que la hace parecer
un host para los ARPANETIMP. Pero también parece un anfitrión de la red de radio por paquetes”.
Una vez definida la noción de puerta de enlace, el siguiente enigma fue la transmisión de paquetes. Al
igual que con ARPANET, la ruta real que recorrieron los paquetes en Internet debería ser
irrelevante. Lo más importante era que los paquetes llegaran intactos. Pero había un problema
desconcertante: todas estas redes (radio por paquetes, SATNET y ARPANET) tenían diferentes
interfaces, diferentes tamaños máximos de paquetes y diferentes velocidades de transmisión. ¿Cómo
podrían estandarizarse todas esas diferencias para poder transportar paquetes entre redes? Una
segunda cuestión se refería a la fiabilidad de las redes. La dinámica de la transmisión por radio y
satélite no permitiría la confiabilidad que tan laboriosamente se construyó en ARPANET. Los
estadounidenses miraron a Pouzin en Francia, quien había elegido deliberadamente un enfoque para
las Cícladas que requería que los anfitriones, en lugar de los nodos de la red, se recuperaran de los
errores de transmisión, trasladando la carga de la confiabilidad a los anfitriones.
Estaba claro que el protocolo de control de red de host a host, que fue diseñado para coincidir con las
especificaciones de ARPANET, tendría que ser reemplazado por un protocolo más independiente. El
desafío para el Grupo de Trabajo de Redes Internacionales fue idear protocolos que pudieran
hacer frente a redes autónomas que operaban bajo sus propias reglas, y al mismo tiempo establecer
estándares que permitieran a los hosts de las diferentes redes comunicarse entre sí. Por ejemplo,
CATENET seguiría siendo un sistema de redes administradas independientemente, cada
una dirigida por su propia gente con sus propias reglas. Pero cuando llegara el momento de que
,
una red intercambiara datos con, digamos, ARPANET, los protocolos de interconexión funcionarían.
A las computadoras de entrada que manejan la transmisión no les importaba la complejidad local oculta
dentro de cada red. Su única tarea sería hacer llegar los paquetes a través de la red al host de destino
en el otro lado, creando el llamado enlace de extremo a extremo.
Una vez establecido el marco conceptual, Cerf y Kahn pasaron la primavera y el verano de
1973 trabajando en los detalles. Cerf presentó el problema a sus estudiantes de posgrado de
Stanford, y él y Kahn se unieron a ellos para atacarlo. Celebraron un seminario que se concentró
en los detalles del desarrollo del protocolo de host a host hasta convertirlo en un estándar
que permita que el tráfico de datos fluya a través de las redes. El seminario de Stanford ayudó
a enmarcar cuestiones clave y sentó las bases para soluciones que surgirían varios años después.
Cerf visitó con frecuencia las oficinas de DARPA en Arlington, Virginia, donde él y Kahn
discutieron el problema durante horas y horas. Durante una sesión maratónica, los dos se quedaron
despiertos toda la noche, garabateando alternativamente en la pizarra de Kahn y paseando por
las calles desiertas de los suburbios, antes de terminar en el Marriott local para desayunar.
Comenzaron a colaborar en un artículo y realizaron su siguiente sesión maratónica
en el vecindario de Cerf, trabajando toda la noche en el Hyatt de Palo Alto.
Ese septiembre, Kahn y Cerf presentaron su artículo junto con sus ideas sobre el nuevo
protocolo al Grupo de Trabajo de la Red Internacional, reuniéndose simultáneamente con una
conferencia de comunicaciones en la Universidad de Sussex en Brighton. Cerf llegó tarde a
Inglaterra porque acababa de nacer su primer hijo. “Llegué en mitad de la sesión y fui recibido
con aplausos porque la noticia del nacimiento me había precedido por correo electrónico”, recuerda
Cerf. Durante la reunión de Sussex, Cerf describió las ideas que él, Kahn y el seminario de
Stanford habían generado. Las ideas se refinaron aún más en Sussex, en largas discusiones
con investigadores de los laboratorios de Davies y Pouzin.
Cuando Kahn y Cerf regresaron de Inglaterra, perfeccionaron su artículo. Ambos hombres tenían
un lado terco. ”Entramos en ese estado de discusión, luego damos un paso atrás y decimos:
'Averigüemos sobre qué es lo que realmente estamos discutiendo'. ”A Cerf le gustaba tener todo
organizado antes de ponerse a escribir; Kahn prefirió sentarse y escribir todo lo que se le ocurrió,
en su propio orden lógico; La reorganización vino después. El proceso de escritura colaborativa
fue intenso. Cerf recuerda: “Era uno de nosotros escribiendo y el otro respirando en su nuca,
componiendo sobre la marcha, casi como dos manos en un bolígrafo”.
A finales de 1973, Cerf y Kahn habían completado su artículo, "Un protocolo para la
intercomunicación de redes de paquetes". Lanzaron una moneda para determinar quién debía
aparecer primero y Cerf ganó el sorteo. El artículo apareció en una revista de ingeniería muy
leída la primavera siguiente.
Al igual que el primer artículo de Roberts que esbozaba la propuesta ARPANET siete años antes,
el artículo de CerfKahn de mayo de 1974 describía algo revolucionario. Según el marco
descrito en el artículo, los mensajes deben encapsularse y desencapsularse en “datagramas”,
de forma muy similar a como se introduce y saca una carta de un sobre y se envía como paquetes
de un extremo a otro. Estos mensajes se denominarían mensajes de protocolo de control
de transmisión, o TCP. El documento también introdujo la noción de puertas de enlace, que leerían
sólo el sobre para que sólo los hosts receptores leyeran el contenido.
El protocolo TCP también abordó los problemas de confiabilidad de la red. En ARPANET, el

IMP de destino era responsable de reensamblar todos los paquetes de un mensaje cuando
llegaba. Los IMP trabajaron duro para asegurarse de que todos los paquetes de un mensaje
pasaran por la red, utilizando acuses de recibo y retransmisión salto a salto. Los IMP también hicieron
Asegúrese de que los mensajes separados se mantuvieran en orden. Debido a todo este trabajo realizado por
los IMP, el antiguo Protocolo de control de red se construyó basándose en la suposición de que la red
subyacente era completamente confiable.
El nuevo protocolo de control de transmisión, con una reverencia a las Cícladas, suponía que
CATENET era completamente poco fiable. Se podrían perder unidades de información y otras podrían
duplicarse. Si un paquete no llegaba o era confuso durante la transmisión y el host emisor no recibía
confirmación, se transmitía un gemelo idéntico.
La idea general detrás del nuevo protocolo era trasladar la confiabilidad de la red a los hosts de destino. "Nos
centramos en la fiabilidad de extremo a extremo", recordó Cerf. “No confíes en nada que esté dentro de esas
redes. Lo único que le pedimos a la red es que tome este trozo de bits y lo haga llegar a través de la
red. Eso es todo lo que pedimos. Simplemente toma este datagrama y haz lo mejor que puedas para
entregarlo”.
El nuevo esquema funcionó de manera muy similar a como se utilizan los contenedores de envío para
transferir mercancías. Las cajas tienen un tamaño y forma estándar. Se pueden llenar con cualquier
cosa, desde televisores hasta ropa interior y automóviles; el contenido no importa. Se desplazan por barco,
ferrocarril o camión. Un contenedor típico de carga viaja por los tres modos en distintas etapas para llegar
a su destino. Lo único necesario para garantizar la compatibilidad cruzada es el equipo
especializado utilizado para transferir los contenedores de un modo de transporte a otro. La carga en sí no
sale del contenedor hasta que llega a su destino.
La invención de TCP sería absolutamente crucial para la creación de redes. Sin TCP, la
comunicación entre redes no podría realizarse. Si se pudiera perfeccionar TCP, cualquiera podría
construir una red de cualquier tamaño o forma, y siempre que esa red tuviera una computadora de
entrada que pudiera interpretar y enrutar paquetes, podría comunicarse con cualquier otra red. Con TCP
en el horizonte, ahora era obvio que las redes tenían un futuro mucho más allá de la ARPANET experimental.
El poder potencial y el alcance de lo que estaban inventando no sólo Cerf y Kahn, sino también Louis
Pouzin en Francia y otros, estaban empezando a darse cuenta de la gente. Si pudieran resolver todos los
detalles, TCP podría ser el mecanismo que abriría mundos.
A medida que más recursos estuvieron disponibles a través de ARPANET y más personas en los sitios se
familiarizaron con ellos, el uso de la red aumentó. Para las noticias del mundo, los primeros usuarios
habituales de la red se conectaban regularmente a una máquina en el SRI, que estaba conectada al cable de
noticias de Associated Press. Durante las horas punta, los estudiantes del MIT se conectaban a algún otro
ordenador de la red para realizar su trabajo. Las imágenes acústicas y holográficas producidas en UC Santa
Barbara se digitalizaron en máquinas de la USC y se llevaron a través de la Red a un procesador de
imágenes en UCSB, donde pudieron manipularse más. El laboratorio de la UCSB estaba equipado con
equipos de procesamiento de imágenes hechos a medida, y los investigadores de la UCSB
tradujeron matemáticas de alto nivel en resultados gráficos para otros sitios. En agosto de 1973, mientras
TCP todavía estaba en la fase de diseño, el tráfico había aumentado a un promedio diario de 3,2
millones de paquetes.
De 1973 a 1975, la Red se expandió a un ritmo de aproximadamente un nuevo nodo cada mes.
El crecimiento avanzaba de acuerdo con la visión original de Larry Roberts, en la que la red estaba
deliberadamente cargada de grandes proveedores de recursos. En este sentido, DARPA había
tenido un éxito maravilloso. Pero el efecto fue un desequilibrio entre la oferta y la demanda; había
demasiados proveedores de recursos y pocos clientes. La introducción de terminales IMP, primero
en Mitre, luego en el Centro de Investigación Ames de la NASA y la Oficina Nacional de Estándares con
hasta sesenta y tres terminales cada uno, ayudó a equilibrar el equilibrio.
El acceso a los propios sitios anfitriones se estaba relajando. La máquina central de la UCSB, por ejemplo,
estaba conectada a minicomputadoras de los departamentos de ciencias políticas, física y química. Se
estaban desarrollando patrones similares en todo el mapa de la red.
Como la mayoría de los primeros sitios anfitriones de ARPANET, el Centro de Computación Avanzada de la
Universidad de Illinois fue elegido principalmente por los recursos que podría ofrecer a otros usuarios de
la Red. En el momento en que Roberts estaba trazando el mapa de la red, estaba previsto que Illinois se
convirtiera en el hogar del nuevo y poderoso ILLIAC IV, una enorme computadora de alta velocidad
única en su tipo que se estaba construyendo en Burroughs Corporation en Paoli, Pensilvania. Se
garantizaba que la máquina atraería a investigadores de todo el país.
Sin embargo, un giro inesperado de las circunstancias llevó a la Universidad de Illinois a convertirse en el
primer consumidor a gran escala de la red en lugar de convertirse en un proveedor de recursos. Los
estudiantes del campus de Urbana estaban convencidos de que el ILLIAC IV se utilizaría para
simular escenarios de bombardeo para la Guerra de Vietnam y para realizar investigaciones de alto secreto en el campus.
Cuando estallaron las protestas en el campus por la inminente instalación, los funcionarios de la
universidad se preocuparon por su capacidad para proteger el ILLIAC IV. Cuando Burroughs terminó
la construcción de la máquina, fue enviada a una instalación más segura administrada por la NASA.
Pero el Centro de Computación Avanzada ya tenía su IMP y acceso completo a la red. Los investigadores
se dieron cuenta rápidamente de la nueva capacidad de explotar recursos informáticos remotos; de
hecho, tan rápido que el Centro rescindió el contrato de arrendamiento mensual de 40.000 dólares de su propio
Burroughs B6700 de alta potencia. En su lugar, la universidad comenzó a contratar servicios
informáticos a través de ARPANET. Al hacer esto, el centro de cálculo redujo su factura de informática casi
a la mitad. Ésta era la economía de escala imaginada por Roberts, llevada a un nivel que superaba las
expectativas de cualquiera. Pronto, el Centro obtenía más del 90 por ciento de sus recursos informáticos a
través de la red.
Las grandes bases de datos diseminadas por la Red estaban ganando popularidad. La Computer
Corporation of America tenía una máquina llamada Datacomputer que era esencialmente un almacén de
información, con datos meteorológicos y sísmicos ingresados en la máquina las 24 horas del día. Cientos
de personas iniciaban sesión cada semana, lo que lo convertía en el sitio más concurrido de la red
durante varios años.
Impulsada por los nuevos tesoros de datos, ARPANET estaba empezando a atraer la atención de investigadores
informáticos de diversos campos. El acceso a la Red todavía estaba limitado a sitios con contratos DARPA,
pero la diversidad de usuarios en esos sitios estaba creando una comunidad de usuarios distinta de los
ingenieros e informáticos que construyeron ARPANET. Los programadores que ayuden a diseñar
estudios médicos podrían vincularse al
Rica base de datos MEDLINE de la Biblioteca Nacional de Medicina. La Escuela de Salud Pública de
UCLA creó una base de datos experimental de evaluaciones de programas de salud mental.
Para servir a la creciente comunidad de usuarios, los investigadores del SRI crearon un recurso único
llamado ARPANETNews en marzo de 1973. La revista, que se distribuía mensualmente en formato tinta
sobre papel, también estaba disponible en la Red. Una mezcla de listados de conferencias, actualizaciones
de sitios y resúmenes de artículos técnicos, el boletín se leía como un chisme de pueblo pequeño
plagado de jerga informática. Uno de los artículos más importantes de ARPANET News fue la
serie "Sitio destacado", en la que los administradores de sistemas de la creciente lista de computadoras host
describieron lo que tenían para ofrecer. En mayo de 1973, la Universidad Case Western Reserve, que
vendía servicios informáticos a usuarios de redes, describió su PDP10 en términos que sonaban
como un anuncio de la sección Contactos: “Case está abierto a propuestas de colaboración que impliquen
trueques de tiempo con otros sitios para trabajos relacionados con intereses aquí y ventas de tiempo como
servicio”.
La comunicación por computadora y el uso de recursos remotos seguían siendo procesos

engorrosos. En su mayor parte, la Red siguió siendo un entorno hostil para el usuario, que requería
conocimientos de programación relativamente sofisticados y una comprensión de los diversos sistemas
que se ejecutaban en los hosts. Estaba creciendo la demanda entre los usuarios de programas de
aplicación de "nivel superior" destinados a ayudar a los usuarios a aprovechar la variedad de
recursos ahora disponibles. Los programas Telnet y de transferencia de archivos existían, pero la comunidad
de usuarios quería más herramientas, como editores comunes y esquemas de contabilidad.
El Centro de Información de Redes del SRI estimó el número de usuarios en unos dos mil.
Pero un grupo de interés de usuarios recién formado, llamado USING, estaba convencido de que había una
brecha entre el diseño de los recursos de la red y las necesidades de las personas que intentaban utilizar
esos recursos. USING, que se imaginaba a sí mismo como un grupo de presión, incluso
un sindicato de consumidores, comenzó inmediatamente a elaborar planes y recomendaciones para
mejorar la prestación de servicios informáticos a través de ARPANET.
Pero DARPA no vio la necesidad de compartir autoridad con un pequeño grupo de vigilancia autoproclamado
formado por personas que la agencia consideraba pasajeros de su vehículo experimental. La iniciativa
murió después de unos nueve meses con un memorando conciso de un director del programa DARPA
llamado Craig Fields, advirtiendo al grupo que se había excedido en sus límites. Sin financiación ni apoyo
oficial para su esfuerzo, los miembros pusieron a USING en un estado de animación suspendida del que
nunca salió.
Otros problemas surgieron para DARPA a medida que el perfil de la red comenzó a aumentar. Al igual que
la insurgencia USING, la mayoría fueron asuntos relativamente menores. Pero juntos ilustraron las tensiones
actuales relacionadas con la gestión de la red por parte de DARPA. Un área de tensión tenía que ver con
los amos del Pentágono de DARPA. La IPTO, en particular, logró mantenerse alejada de las investigaciones
más descaradamente militares. Pero mientras los estudiantes de Illinois estaban equivocados acerca de que
el ILLIAC IV fuera usado para misiones de bombardeo simuladas contra Vietnam del Norte, había
planes para usarlo en escenarios de ataques nucleares contra la Unión Soviética. De manera similar,
investigadores de todo tipo utilizaron información sísmica almacenada en el servidor de base de datos de
Computer Corporation of America (CCA), información que se estaba recopilando para apoyar
proyectos del Pentágono que implicaban pruebas atómicas subterráneas.
A finales de la década de 1960, el creciente malestar político, tanto violento como no violento, tomó por
sorpresa al ejército estadounidense. La inteligencia del ejército sabía todo sobre Praga, Berlín y Moscú,
pero ahora el Pentágono estaba contemplando Newark, Detroit y Chicago. El Ejército recopiló información
de docenas de ciudades estadounidenses sobre la ubicación de estaciones de policía y
bomberos, hospitales, etc. Alguien en el Pentágono pensó que sería una buena idea hacer un seguimiento
también de los alborotadores locales.
En 1972 estalló la protesta pública por la recopilación de información por parte del ejército y se ordenó la
destrucción inmediata de los archivos. Pero tres años más tarde, surgieron acusaciones de que oficiales
de inteligencia del ejército habían utilizado ARPANET para mover los archivos a una nueva ubicación.
Cuando se supo la historia, el hecho de que existiera algo como ARPANET fue una novedad para la
mayoría de los estadounidenses. El hecho de que la historia se contara en los términos más draconianos
y de capa y espada sólo contribuyó a la tormentosa reacción. El resultado fue una investigación del
Senado en la que se pidió a DARPA que explicara cómo estaba utilizando ARPANET.
DARPA finalmente demostró que los archivos del Ejército no se habían movido en ARPANET al
revisar cientos de rollos de impresiones de Teletipo que habían sido almacenados en un espacio
polvoriento en BBN. DARPA fue reivindicada, pero lo último que ARPANET necesitaba era lo que se
percibía como un enredo con las operaciones clandestinas del Ejército.
Cambios en DARPA
Las discusiones sobre cómo DARPA finalmente se desharía de la responsabilidad operativa de la red ya
habían comenzado alrededor de 1971. DARPA se había propuesto vincular las capacidades de
procesamiento centrales en los principales centros de investigación de ciencias informáticas de Estados
Unidos y, en lo que ahora a la agencia concernía, lo había logrado. . Su misión era la investigación.
No se suponía que estuviera en el negocio de operar una red. Ahora que el sistema estaba en
funcionamiento, se estaba convirtiendo en una carga para otras prioridades. Ya era hora de que DARPA
se deshiciera del papel de proveedor de servicios.
Manejar la transición fue un asunto delicado. ARPANET era ahora una herramienta valiosa y el objetivo de
Roberts era garantizar su desarrollo continuo. Encargó varios estudios para ayudar a determinar la
mejor opción. Parecía que la mejor ruta era mantener un esfuerzo de investigación de redes, pero
vender la red a un contratista privado. ¿Pero vender a quién? El mercado de las redes de comunicaciones
de datos todavía estaba en gran medida inexplorado y las grandes empresas de comunicaciones seguían
siendo tan escépticas como siempre acerca de la tecnología DARPA.
Cuando Roberts se puso en contacto con AT&T para ver si quería hacerse cargo de , AT&T
ARPANET, formó un comité de personal corporativo y de Bell Labs y estudió la idea durante meses.
AT&T podría haber sido propietario de la red como un servicio monopólico, pero al final declinó.
"Finalmente llegaron a la conclusión de que la tecnología de paquetes era incompatible con la red de
AT&T", dijo Roberts.
Otros no estaban tan ciegos ante las perspectivas de las redes informáticas. En julio de 1972 tres
ingenieros dejaron BBN para formar una empresa que comercializaría una red comercial llamada Packet
Communications Incorporated. Y la propia BBN había hablado con Roberts sobre
comprar la red y crear una filial para operarla. Los transportistas comerciales pequeños y especializados
como estos eran la solución obvia al problema de DARPA.
Pero pronto Roberts tuvo un nuevo problema. A principios de 1973, BBN lo reclutó para dirigir una
nueva filial llamada TELENET (que no debe confundirse con Telnet, el programa para inicios de sesión
remotos), que comercializaría un servicio privado de conmutación de paquetes. Ahora que no podía
recomendar una venta por parte del gobierno a TELENET, Roberts dispuso
que ARPANET se transfiriera temporalmente a la Agencia de Comunicaciones de Defensa, la misma
agencia a la que Baran se había negado a permitir que construyera su red diez años antes. Los
generales, mayores y capitanes todavía eran ligeramente más receptivos a la idea de una red de
conmutación de paquetes que AT&T, pero Roberts esperaba que se tratara sólo de un acuerdo
provisional.
Después de haber decidido aceptar el puesto en TELENET, a Roberts le tocaba ahora la tarea de
encontrar un sucesor. Sin embargo, la Oficina de Técnicas de Procesamiento de Información de DARPA ya
no tenía el atractivo que alguna vez tuvo para los académicos. Roberts se acercó a un par de sus
investigadores principales en las universidades, pero las personas que tenían programas de investigación
activos no querían abandonarlos. Otros estaban preocupados por los recortes salariales que tendrían que
aceptar para venir a la oficina de DARPA.
Cuando Licklider se enteró de los problemas que estaba teniendo Roberts, se ofreció a regresar si
Roberts lo necesitaba. Roberts sabía que era sólo un gesto por parte de Licklider. Lick ahora estaba
felizmente atrincherado en el MIT. Pero después de seis meses de búsqueda, Roberts decidió que no
tenía otra opción. Cuando Roberts llamó a la oficina de Lick en el MIT, le dijeron que Lick estaba de gira a
pie por Inglaterra. Roberts lo localizó en el centro de Gales y le preguntó si hablaba en serio acerca de
aceptar el trabajo. Licklider dijo que sí. "Nunca vi a Larry tan feliz como cuando finalmente consiguió
su reemplazo, porque estaba listo para partir", recordó un colega de Roberts. “Creo que parte de su alegría
también fue el hecho de que Lick iba a aceptarlo, porque le agradaba. Todo el mundo lo hizo”.
Uno de los primeros problemas que enfrentó Lick a su regreso fue uno incómodo que involucraba a BBN, su
antiguo empleador. BBN se negaba a publicar el código fuente de IMP, el programa operativo original
escrito por los IMP Guys cinco años antes.
El aparente impulso de BBN de controlar todos los aspectos de la red creó cierta tensión desde el principio.
Len Kleinrock y su grupo del Centro de Medición de Redes de UCLA lo encontraron particularmente
frustrante. El trabajo del centro era encontrar problemas en la red, pero cuando lo hicieron, BBN se negó
a ayudar. "Cada vez que encontrábamos un error o una ineficiencia en el software, alertábamos a Heart
específicamente, y la respuesta que obteníamos era casi un brazo rígido", dijo Kleinrock. “Él decía: 'Mira, la
red está funcionando, tengo una red que mantener en funcionamiento y pondremos tu comentario en la
cola'. No pudimos arreglarlo nosotros mismos porque no teníamos el código fuente”.
El problema de la propiedad intelectual finalmente estalló cuando los ingenieros que dejaron BBN para
iniciar su propia empresa solicitaron expresamente a su antiguo empleador que les entregara el código
fuente de IMP. Cuando BBN se negó, apelaron a DARPA. Si bien mantener el código fuente como
propietario suele ser prerrogativa de la empresa que lo desarrolla, el código fuente de IMP era diferente,
ya que había sido desarrollado por BBN con fondos federales.
Además, BBN estaba a punto de crear la filial TELENET, que competiría con la empresa fundada por
los ingenieros. En DARPA existía cierta preocupación de que si alguien en el Congreso o el
cuerpo de prensa se aferraba al hecho de que la filial de BBN y nadie más tenía acceso a la
tecnología IMP patrocinada por el Departamento de Defensa, la agencia podría tener un
problema importante en sus manos.
Frank Heart y Dave Walden de BBN argumentaron que dado que el código fuente se cambiaba
con frecuencia para mejorar el rendimiento o corregir errores, la empresa se sentía incómoda con
la distribución de software que quedaría obsoleto. La empresa se mantuvo firme.
Steve Crocker, para entonces director del programa DARPA que supervisaba la mayoría de
los contratos de BBN, se hizo cargo de la situación. Tenía el control de unos 6 millones de dólares en
trabajo al año en BBN, aproximadamente una cuarta parte de los ingresos brutos de la empresa.
"Consideré seriamente trasladar todo el trabajo que estábamos apoyando en BBN a otros lugares
porque no podíamos cerrar con ellos los derechos de datos del código IMP", dijo. Y le hizo saber
a BBN lo que estaba pensando.
Lick había tenido una larga asociación con BBN y tenía un gran respeto por la gente de allí, pero
estaba consternado por su postura. La reacción en toda la comunidad informática fue más o
menos la misma. Finalmente, en respuesta directa a la amenaza de Crocker, BBN acordó proporcionar
el código a quien lo solicitara, cobrando una tarifa nominal de gestión. "Esta fue sólo una versión
temprana de problemas mucho más serios de derechos de propiedad intelectual que surgieron en
toda la industria durante las siguientes décadas", dijo Crocker.
Con la ayuda de Bob Kahn, Licklider también terminó el trabajo de derivar la red a la Agencia de
Comunicaciones de Defensa. A pesar de las investigaciones anteriores de Roberts sobre la venta de
la red, las reglas federales exigían que un recurso tan rico como ARPANET no pudiera simplemente
venderse a una parte externa hasta que el Departamento de Defensa determinara si tenía necesidad
de la Red en Defensa. La agencia finalmente decidió que sí. En el verano de 1975, DCA asumió
la gestión de la red de DARPA. Ahora DCA estableció una política operativa para la red.
DCA decidió cosas como dónde y cuándo se instalarían nuevos nodos y cuál debería ser la
configuración de las líneas de datos. Y BBN retuvo el contrato para la operación de la red, lo que
significaba que la empresa cumplía las decisiones tomadas por DCA. Poco después de realizada la
transición, Lick regresó al MIT, donde pasaría el resto de su carrera.
Pronto, todos en BBN notaron un número cada vez mayor de formularios que debían completarse,
incluso para los trabajos más pequeños. La burocracia del DCA también inquietó a muchos universitarios.
“La agencia generó una avalancha de memorandos de coroneles y generales sobre cosas que a
uno se le permitía y no se le permitía hacer”, recordó Brian Reid. Unos meses después de que
DCA se hiciera cargo de ARPANET, varios de los estudiantes de posgrado del departamento de
informática de Stanford asistieron a una fiesta de Halloween vestidos como coroneles.
Liberado de las tareas de gestión del día a día, DARPA ahora pudo concentrarse en desarrollar los
nuevos protocolos CATENET. En 1975, Yogen Dalal, un estudiante de posgrado de Stanford,
había pulido el protocolo de control de transmisión del artículo de 1974 de Cerf y Kahn hasta
convertirlo en un conjunto de especificaciones concretas. La especificación TCP fue enviada a tres
Lugares separados para implementación simultánea: BBN, el laboratorio de computación de Cerf en

Stanford y el University College de Londres.
Casi al mismo tiempo, Kahn y Steve Crocker comenzaron a hablar con Cerf sobre la posibilidad de aceptar
un trabajo como director del programa DARPA en Washington. “Volé hasta allí y aterricé en medio
de una gran tormenta de nieve y pensé: no quiero vivir en esta parte del país”, recuerda Cerf.
“Entonces dije que no. Pero la verdadera razón era que tenía miedo de no hacer un buen trabajo.
Pensé que sería una posición muy visible y que si me equivocaba, todo el mundo lo sabría”.
Un año después, Kahn y Crocker lo intentaron de nuevo. Esta vez Cerf aceptó. “Me estaba cansando
un poco de estar tan fragmentado en Stanford. No pude realizar ninguna investigación. Entonces
pensé: ¿Por qué no ir a DARPA y tener un impacto mayor? Porque en lugar de los pequeños presupuestos
que obtuve en Stanford para mi trabajo, en DARPA tendría la oportunidad de tener un impacto mayor con
más dinero para gastar”.
Como director de programas, a Cerf se le asignó la responsabilidad de los programas de radio por paquetes,
satélites por paquetes y de investigación en lo que ahora se llamaba simplemente ARPA Internet. Cerf
también continuó trabajando intensamente para perfeccionar la especificación TCP. En octubre de 1977 se
produjo un hito, cuando Cerf, Kahn y una docena de personas más demostraron el primer sistema de tres
redes con radio por paquetes, ARPANET y SATNET, todos funcionando en conjunto. Los mensajes
viajaban desde el área de la Bahía de San Francisco a través de una red de radio por paquetes, luego
ARPANET y luego un enlace satelital dedicado a Londres, de regreso a través de la red de paquetes por
satélite y a través de ARPANET nuevamente, y finalmente al Instituto de Ciencias de la Información
de la Universidad del Sur de California ( ISI) en Marina del Rey. Los paquetes viajaron 94.000 millas sin
perder un solo bit.
Durante un descanso de una reunión que Cerf presidió en ISI para discutir el TCP a principios de 1978,
Cerf, Postel y Danny Cohen, un colega de Postel en ISI, entablaron una discusión en un pasillo.
“Estábamos dibujando diagramas en un gran trozo de cartón que apoyamos contra la pared del pasillo”,
recuerda Postel. Cuando se reanudó la reunión, el trío presentó una idea al grupo: romper la parte del
Protocolo de Control de Transmisión que se ocupa del enrutamiento de paquetes y formar un Protocolo
de Internet o IP separado.
Después de la división, TCP sería responsable de dividir los mensajes en datagramas, volver a
ensamblarlos en el otro extremo, detectar errores, reenviar todo lo que se perdió y volver a colocar los
paquetes en el orden correcto. El Protocolo de Internet, o IP, sería responsable de enrutar los datagramas
individuales.
"Recuerdo haber tenido una directriz general sobre lo que se incluía en IP versus lo que se incluía en
TCP", recordó Postel. "La regla era '¿Las puertas de enlace necesitan esta información para mover el
paquete?' Si no, entonces esa información no va en IP". Este giro en el protocolo fue inspirado por
un grupo de ingenieros del Centro de Investigación Palo Alto de Xerox Corporation que habían asistido
al seminario de Stanford. El equipo de Xerox había resuelto problemas similares a una escala patentada
más pequeña definiendo una familia de protocolos llamada PARC Universal Packet o PUP. Una vez que
Postel decidió que crear un protocolo separado era lo correcto, se propuso asegurarse de que se hiciera.
Con una clara separación de los protocolos, ahora era posible construir puertas de enlace rápidas y
relativamente económicas,
lo que a su vez impulsaría el crecimiento de la interconexión de redes. En 1978, TCP se había convertido
oficialmente en TCP/IP.
ETHERNET
En 1973, justo cuando Cerf y Kahn habían comenzado a colaborar en el concepto de interconexión
de redes, Bob Metcalfe de Xerox PARC estaba inventando las bases tecnológicas para un nuevo tipo
de red. Llamada red de corta distancia o de área local, la red de Metcalfe conectaría computadoras no en
diferentes ciudades sino en diferentes habitaciones.
Metcalfe había recibido sus títulos universitarios en ingeniería eléctrica y administración del MIT y
se había matriculado en Harvard para realizar estudios de posgrado. Pero odió a Harvard de inmediato.
“Harvard está llena de gente con mucho dinero”, dijo. “El MIT está lleno de falta de dinero. Era una cuestión de
clase”.
Metcalfe aceptó un trabajo en el MIT, donde se sentía más cómodo. El Instituto estaba a punto de unirse a
ARPANET y se le asignó la tarea de construir la interfaz entre el PDP10 del MIT y su IMP. Harvard también
tenía un PDP10 y Metcalfe se ofreció a crear una interfaz duplicada para entregársela a Harvard. Pero
la gente de Harvard rechazó la oferta.
"Dijeron que no podían permitir que un estudiante de posgrado hiciera algo tan importante", dijo Metcalfe. Los
funcionarios de Harvard decidieron que BBN lo hiciera. BBN, a su vez, le dio el trabajo a su estudiante de
posgrado residente, Ben Barker, quien reclutó a John McQuillan, un compañero de posgrado de Harvard,
para que lo ayudara.
Aunque estaba matriculado en Harvard, Metcalfe permaneció en el MIT para trabajar en su tesis, un examen
de ARPANET. Cuando Metcalfe presentó el trabajo, Harvard rechazó la tesis terminada por considerarla
insuficientemente teórica (demasiada ingeniería y poca ciencia, le dijeron). El rechazo fue vergonzoso para
Metcalfe, quien acababa de aceptar un trabajo en el Centro de Investigación de Palo Alto de Xerox Corporation
después de convencer a su esposa de que dejara su trabajo para unirse a él. De todos modos fue a Xerox PARC
y empezó a buscar un tema más teórico para su tesis.
Luego, en 1972, mientras realizaba negocios relacionados con DARPA para PARC, Metcalfe se quedó
en la casa de Washington de su amigo Steve Crocker. Crocker había reunido a algunos de los mejores técnicos
de los primeros sitios para ayudar a los sitios nuevos y llamó a estas personas "facilitadores de redes".
Metcalfe, que se había convertido en una especie de experto en ARPANET en el MIT, era uno de ellos.
Crocker acababa de recibir la visita de Norm Abramson, el arquitecto principal de la red ALOHA
de la Universidad de Hawaii. La noche de la visita de Metcalfe, Crocker dejó afuera uno de los artículos de
Abramson sobre la red ALOHA. Metcalfe lo recogió y lo leyó antes de irse a dormir. El periódico lo mantuvo
despierto gran parte de la noche. "Las matemáticas del artículo no sólo eran familiares sino exasperantes", dijo,
"porque hacían las típicas suposiciones inexactas que la gente hace para que sus modelos funcionen".
El encuentro casual de Metcalfe con el artículo de Abramson cambiaría su vida. "Me propuse crear un nuevo
modelo para el sistema ALOHA". A las pocas semanas, estaba en una fotocopiadora.
viaje financiado a la Universidad de Hawaii. Se quedó un mes y antes de regresar a casa había añadido
a su tesis un análisis extenso del sistema ALOHA. Fue sólo el impulso teórico que necesitaba la tesis.
Cuando volvió a enviar el trabajo, fue aceptado.
Pero el sistema ALOHA le dio a Metcalfe mucho más que un doctorado. Xerox PARC estaba en el
proceso de desarrollar una de las primeras computadoras personales, llamada Alto. La empresa vio
que los clientes querrían conectar las máquinas, por lo que a Metcalfe, uno de los expertos en redes
residentes, se le asignó la tarea de unir los Altos. Sin un modelo de almacenamiento y reenvío, era
imposible evitar que los paquetes de datos colisionaran. Pero simplemente reducir ARPANET mediante
la construcción de una subred de computadoras de almacenamiento y reenvío tipo IMP habría
sido prohibitivamente costoso para un sistema diseñado para funcionar en un edificio de oficinas.
Metcalfe tuvo una idea, tomada directamente de ALOHANET; de hecho, la llamaría Red Alto Aloha:
dejar que los paquetes de datos colisionen y luego retransmitirlos en un momento aleatorio.
Pero la idea de Metcalfe difería en varios aspectos del sistema hawaiano. Por un lado, su red sería mil
veces más rápida que ALOHANET. También incluiría detección de colisiones. Pero quizás lo más
importante es que la red de Metcalfe estaría cableada y no funcionaría mediante ondas de radio sino
mediante cables que conectarían computadoras en diferentes habitaciones o entre grupos de
edificios.
Una computadora que desea enviar un paquete de datos a otra máquina (por ejemplo, una
estación de trabajo de escritorio que envía a una impresora) escucha el tráfico en el cable. Si el
ordenador detecta transmisiones conflictivas, espera, normalmente unas milésimas de segundo.
Cuando el cable está en silencio, la computadora comienza a transmitir su paquete. Si, durante la
transmisión, detecta una colisión, se detiene y espera antes de volver a intentarlo, normalmente
unos cientos de microsegundos. En ambos casos, la computadora elige el retraso aleatoriamente,
minimizando la posibilidad de reintentar en el mismo instante seleccionado por cualquier dispositivo
que envió la señal que provocó la colisión. A medida que la red se vuelve más ocupada, las
computadoras retroceden y reintentan en intervalos aleatorios más largos. Esto mantiene el proceso eficiente y el canal intacto.
"Imagínese que está en una fiesta y varias personas están conversando", dijo Butler
Lampson, quien ayudó a Metcalfe a desarrollar la idea, describiendo el sistema. “Una persona deja
de hablar y otra quiere hablar. Bueno, no hay garantía de que sólo una persona quiera hablar; tal vez
varios lo hagan. No es raro que dos personas empiecen a hablar a la vez. ¿Pero qué sucede
normalmente? Generalmente ambos se detienen, hay un poco de vacilación y luego uno comienza de
nuevo”.
Metcalfe y Lampson, junto con los investigadores de Xerox David Boggs y Chuck Thacker, construyeron
su primer sistema Alto Aloha en el laboratorio de Bob Taylor en Xerox PARC. Para su gran deleite,
funcionó. En mayo de 1973, Metcalfe sugirió un nombre, recordando el hipotético medio luminífero
inventado por los físicos del siglo XIX para explicar cómo la luz atraviesa el espacio vacío.
Rebautizó el sistema como Ethernet.
CSNET
DCA, la agencia encargada de ARPANET, no fue la única agencia de I+D en Washington que se volvió
burocrática. En ningún lugar de Washington ya uno podía entrar a la oficina de su jefe con una idea
brillante para un proyecto y salir veinte minutos después con un millón de dólares de apoyo. A mediados de
la década de 1970, la única organización que guardaba algún parecido con la antigua ARPA era la Fundación
Nacional de Ciencias. La fundación fue creada en 1950 para promover el progreso de la ciencia mediante
la financiación de la investigación básica y el fortalecimiento de la educación científica. A finales de
la década de 1970, NSF estaba en auge en el campo de la informática.
La NSF no sólo era una nueva fuente probable de fondos suficientes, sino que también era la
única organización cuyos funcionarios podían actuar en nombre de toda la comunidad científica.
DARPA había proporcionado la base de investigación y la nueva tecnología. Ahora NSF lo llevaría a una
comunidad más grande.
Los funcionarios de la NSF llevaban algún tiempo interesados en crear una red para la comunidad
académica de informática. En un informe de 1974, un comité asesor de la NSF concluyó que tal
servicio “crearía un entorno de frontera que ofrecería comunicación avanzada, colaboración y el intercambio
de recursos entre investigadores geográficamente separados o aislados”. En ese momento, la
NSF estaba principalmente preocupada por estimular el desarrollo de lo que todavía era una
disciplina incipiente. Tal vez porque la informática todavía era un campo emergente en la mayoría de los
campus, la idea no surgió gran cosa.
A finales de la década de 1970, los departamentos de informática se habían multiplicado. Las ventajas de
ARPANET ahora estaban claras. La rápida comunicación electrónica con colegas y el fácil intercambio de
recursos significaron que tareas que normalmente tomaban semanas ahora podían completarse en horas.
El correo electrónico creó un nuevo mundo de samizdat rápido, reemplazando los lentos servicios postales
y las conferencias poco frecuentes. La red se había vuelto tan esencial para la investigación en informática
como lo eran los telescopios para los astrónomos.
Pero ARPANET amenazaba con dividir a la comunidad de investigadores informáticos en ricos y pobres.
En 1979 había alrededor de 120 departamentos académicos de informática en todo el país, pero
sólo quince de los sesenta y un sitios ARPANET estaban ubicados en universidades. Tanto los candidatos
a profesores como los estudiantes de posgrado estaban empezando a aceptar o rechazar ofertas basadas
en si una escuela tenía o no acceso a la Red, poniendo a las instituciones de investigación sin un nodo
ARPANET en desventaja en la carrera por conseguir los mejores académicos y las becas de investigación
que les siguieron.
Más importante aún, un éxodo de talento informático de la academia a la industria había causado un temor
en todo el país de que Estados Unidos no pudiera capacitar a su próxima generación de científicos
informáticos. El atractivo de los salarios del sector privado era parte del problema. Pero los científicos
no sólo estaban siendo atraídos hacia la industria; ellos también estaban siendo empujados. Las instalaciones
informáticas de muchas universidades estaban obsoletas o carecían de potencia, lo que dificultaba que las
personas en los campus se mantuvieran al tanto del campo informático en rápida evolución.
Poco se podía hacer respecto de las discrepancias salariales entre la academia y la industria. Pero el
problema de recursos era esencialmente el mismo que había enfrentado DARPA una década antes.
Una red de informáticos reduciría la necesidad de duplicar esfuerzos.
Y si esta red estuviera abierta a sitios de investigación privados, habría menos presión sobre los investigadores
para que abandonaran las universidades para mantenerse al día con su disciplina.
Aunque la solución parecía clara, implementarla resultó ser otra cuestión. Vincular los departamentos de
informática a ARPANET estaba fuera de discusión. Para que se les asignara un sitio, las universidades tenían que
participar en tipos específicos de investigación financiada por el gobierno, generalmente relacionadas con la
defensa. Incluso entonces, era costoso asignar nuevos sitios. Las conexiones
ARPANET tenían un solo tamaño: extra grande. El sistema utilizaba costosas líneas telefónicas arrendadas y
cada nodo tenía que mantener dos o más enlaces a otros sitios. Como resultado, mantener un sitio ARPANET
cuesta más de 100.000 dólares cada año, independientemente del tráfico que genere.
Los informáticos tuvieron que inventar otra forma. En mayo de 1979, Larry Landweber, jefe del departamento de
informática de la Universidad de Wisconsin, invitó a representantes de seis universidades a
Madison para discutir la posibilidad de construir una nueva red de investigación en informática, que se llamaría
CSNET. Aunque DARPA no pudo brindar apoyo financiero, la agencia envió a Bob Kahn a la reunión como
asesor. La NSF, que había planteado la cuestión de las redes académicas cinco años antes, envió a Kent Curtis,
jefe de su división de investigación informática. Después de la reunión, Landweber pasó el verano trabajando con
Peter Denning de Purdue, Dave Farber de la Universidad de Delaware y Tony Hearn, quien recientemente
había dejado la Universidad de Utah para incorporarse a RAND Corporation, para desarrollar una propuesta
detallada para la nueva red.
Su propuesta pedía una red abierta a investigadores en informática del mundo académico, gubernamental e
industrial. El medio subyacente sería un proveedor de servicios comerciales como TELENET. Porque
CSNET estaría usando enlaces más lentos que los costosos usados por ARPANET. La red estaría gestionada por
un consorcio de , y no insistiera en vínculos redundantes, el sistema sería mucho menos
once universidades, con un coste estimado de 3 millones de dólares en cinco años. Debido a la política
del DCA que restringe el acceso a ARPANET únicamente a los contratistas del DOD,
la propuesta no contenía ninguna puerta de enlace entre las dos redes. Un borrador de la propuesta distribuido por
el grupo recibió elogios entusiastas. Enviaron la versión final a NSF en noviembre de 1979.
Pero después de casi cuatro meses de revisión por pares, NSF rechazó la propuesta, aunque seguía
entusiasmada con la idea CSNET. Por eso, NSF patrocinó un taller para superar las deficiencias que los revisores
de NSF encontraron en el borrador de la propuesta. Landweber y compañía volvieron a sus mesas de
dibujo.
En el verano de 1980, el comité de Landweber volvió con una manera de adaptar la arquitectura de CSNET
para proporcionar acceso asequible incluso al laboratorio más pequeño. Propusieron una estructura de
tres niveles que incluía ARPANET, un sistema basado en TELENET y un servicio de correo electrónico llamado
PhoneNet. Las puertas de enlace conectarían los niveles en un todo perfecto.
Según la nueva propuesta, NSF apoyaría a CSNET durante un período de inicio de cinco años, después del cual
sería financiado en su totalidad mediante tarifas de usuario. Los costos anuales de una universidad, una
combinación de cuotas y cargos de conexión, oscilaban entre unos pocos miles de dólares por el servicio PhoneNet
(principalmente para las conexiones telefónicas de larga distancia) hasta 21.000 dólares por un sitio TELENET.
En cuanto a cómo se gestionaría la red (una preocupación de la Junta Nacional de Ciencias, el órgano rector
de la NSF), el plan adoptó un enfoque novedoso. Durante los dos primeros años, la propia NSF desempeñaría
el papel de gestora del consorcio universitario. Después de eso, la responsabilidad pasaría a la
Corporación Universitaria para la Investigación Atmosférica. UCAR estaba familiarizada con el trabajo
informático avanzado y tenía la experiencia para manejar un proyecto que involucraba a tantas instituciones
académicas. Más importante aún, la Junta Científica conocía a UCAR y confiaba en sus habilidades de
gestión. La Junta acordó aportar casi 5 millones de dólares para el proyecto CSNET.
En junio de 1983, más de setenta sitios estaban en línea, obtenían servicios completos y pagaban cuotas
anuales. Al final del período de cinco años de apoyo de la NSF en 1986, casi todos los departamentos de
informática del país, así como un gran número de sitios privados de investigación informática, estaban
conectados. La red era financieramente estable y financieramente autosuficiente.
La experiencia que NSF adquirió en el proceso de iniciar CSNET allanó el camino para más proyectos de
NSF en redes de computadoras.
A mediados de la década de 1980, tras el éxito de CSNET, comenzaron a surgir más redes. Una, llamada
BITNET (la red Porque ya es hora), era una red cooperativa entre sistemas IBM sin restricciones de membresía.
Otro, llamado UUCP, fue construido en Bell Laboratories para la transferencia de archivos y la ejecución
remota de comandos.USENET , que comenzó en
1980 como un medio de comunicación entre dos máquinas (una en la Universidad de Carolina del Norte
y otra en la Universidad de Duke), floreció hasta convertirse en una red de noticias distribuidas utilizando
UUCP. La NASA tenía su propia red llamada Red de Análisis de Física Espacial o SPAN. Debido a que este
creciente conglomerado de redes podía comunicarse utilizando los protocolos TCP/IP, gradualmente el conjunto
de redes pasó a denominarse "Internet", tomando prestada la primera palabra de "Protocolo de
Internet".
A estas alturas, había surgido una distinción entre "Internet" con una i minúscula e "Internet" con una I
mayúscula. Oficialmente, la distinción era simple: "Internet" significaba cualquier red que utilizara TCP/
IP, mientras que "Internet" significaba la red pública, subsidiada por el gobierno federal. red que estaba formada
por muchas redes vinculadas, todas ejecutando los protocolos TCP/IP. En términos generales, una
“Internet” es privada y la “Internet” es pública. La distinción realmente no importó hasta mediados de la década
de 1980, cuando los proveedores de enrutadores comenzaron a vender equipos para construir redes privadas de Internet.
Pero la distinción rápidamente se desdibujó a medida que las Internet privadas construyeron puertas de enlace a la
Internet pública.
Aproximadamente al mismo tiempo, corporaciones privadas e instituciones de investigación estaban

construyendo redes que utilizaban TCP/IP. El mercado se abrió para los enrutadores. Las puertas de
enlace eran la variación de interconexión de los IMP, mientras que los enrutadores eran la versión
producida en masa de las puertas de enlace, que conectaban las redes de área local a ARPANET. En algún
momento a principios de la década de 1980, Alex McKenzie y otro ingeniero de BBN se acercaron a un
vicepresidente de marketing de BBN y pensaron que la empresa debería entrar en el negocio de la
construcción de enrutadores. Tiene sentido. BBN había construido los IMP y los TIP, e incluso la primera
puerta de enlace a Internet como parte del programa de radio por paquetes. Pero el encargado de marketing, después de hacer algunas
Después de realizar rápidos cálculos en su cabeza, decidió que los enrutadores no eran muy prometedores. Él estaba
equivocado.
También a mediados de la década de 1980 surgieron varias redes de investigación académica en Europa.
En Canadá estaba CDNet. Sin embargo, gradualmente, cada red construyó una puerta de entrada a
Internet patrocinada por el gobierno de Estados Unidos y las fronteras comenzaron a disolverse. Y
gradualmente Internet pasó a significar la matriz flexible de redes TCP/IP interconectadas en todo el mundo.
A estas alturas, todos los científicos investigadores con apoyo de la NSF (no sólo los informáticos,
sino también los oceanógrafos, astrónomos, químicos y otros) llegaron a creer que estaban en
desventaja competitiva a menos que tuvieran acceso a la red. Y CSNET, que iba a ser utilizado sólo por
departamentos académicos de informática, no era la respuesta. Pero CSNET fue el trampolín hacia el
mayor logro de NSF, NSFNET.
El modelo de CSNET convenció a NSF de la importancia de la creación de redes para la comunidad

científica. Las ventajas profesionales que se obtenían de la capacidad de comunicarse con los
compañeros eran incalculables. Y como la agencia había estado trabajando tan estrechamente con
los científicos informáticos, internamente contaba con varias personas que entendían las redes y
podían ayudar a administrar los programas. Pero NSF no tenía los medios para construir una red
nacional. Mantener el ARPANET solo cuesta millones de dólares al año.
La creación en 1985 de cinco centros de supercomputación repartidos por Estados Unidos ofreció una
solución. Los físicos y otros estaban haciendo campaña por una “columna vertebral” para interconectar
los centros de supercomputadoras. La NSF acordó construir la red troncal, que se llamará
NSFNET. Al mismo tiempo, la NSF ofreció que si las instituciones académicas de una región
geográfica formaran una red comunitaria, la agencia le daría a la red comunitaria acceso a la red
troncal. La idea no era sólo ofrecer acceso sino también dar acceso a las redes regionales entre sí.
Con esta disposición, cualquier computadora podría comunicarse con cualquier otra a través de una serie
de enlaces.
En respuesta, se formaron aproximadamente una docena de redes regionales en todo el país. Cada uno
tenía la franquicia exclusiva en esa región para conectarse a la red troncal de NSFNET. En el norte
del estado de Nueva York, se formó NYSERNET (Red de Investigación Educativa del Estado de Nueva York).
En San Diego existía la Red de Investigación Educativa de California, o CERFnet (aunque Vint
Cerf no tenía relación con la red, los fundadores de CERFnet lo invitaron a su inauguración). La financiación
de las redes regionales provendría de las propias empresas miembros. La NSF proporcionó la columna
vertebral esencialmente como un “bien gratuito” para la comunidad académica en el sentido de que las
redes regionales no pagaban por utilizarla. Por otro lado, las subvenciones de la NSF a las universidades
para conectar sus campus a la red regional siempre fueron subvenciones de dos años y
estrictamente no renovables. Esto significó que, después de dos años, las universidades pagaban de
su propio bolsillo el coste de la conexión regional. Los cargos típicos oscilaban entre 20.000 y
50.000 dólares al año por una conexión de alta velocidad.
TCP/IP frente a OSI

En 1982, Vint Cerf anunció que dejaría ARPA para trabajar en MCI.
A principios de ese año había conocido a un ejecutivo de MCI cuyo trabajo era introducir a MCI en el negocio
de los datos. “Su idea era construir una oficina de correos digital”, recuerda Cerf. “La idea me atrapó
inmediatamente”. La reacción ante la partida de Cerf fue de shock. Un colega lloró.
“Vint era lo más parecido a un general que teníamos nosotros”, dijo otro.
Cerf se marchaba en un momento crítico para la red. ARPANET estaba a punto de hacer su transición oficial a
TCP/IP, pero nadie sabía con certeza si el gobierno de Estados Unidos hablaba en serio de adoptarlo. El
Departamento de Defensa había respaldado TCP/IP, pero la rama civil del gobierno no. Y había una creciente
preocupación de que la Oficina Nacional de Estándares decidiera apoyar un estándar rival emergente para
la interconexión de redes llamado Modelo de Referencia OSI.
Varios años antes, la Organización Internacional de Normalización, ISO, había comenzado a desarrollar su propio
modelo de “referencia” de interconexión de redes, llamado OSI, o interconexión de sistemas abiertos.
Desde la década de 1940, ISO había especificado estándares mundiales para cosas que iban desde copas
para degustar vino hasta tarjetas de crédito, películas fotográficas y computadoras. Esperaban que su modelo OSI
llegara a ser tan omnipresente en las computadoras como lo fueron las baterías doble A en las radios portátiles.
Se estaba gestando una especie de batalla en líneas familiares, que recordaban la confrontación entre AT&T
y los inventores de la conmutación de paquetes durante el nacimiento de ARPANET. Del lado de OSI había una
burocracia arraigada, con una fuerte actitud de "sabemos lo mejor", condescendiente y ocasionalmente
desdeñosa. “Había una cierta actitud entre ciertas partes de la comunidad OSI cuyo mensaje era: 'Es hora de
enrollar tu red académica de juguete'”, recordó un ferviente devoto de TCP/IP. "Pensaban que TCP/IP e Internet
eran sólo eso: un juguete académico". Nadie afirmó jamás que lo que había comenzado con el Grupo de
Trabajo de la Red y continuado en toda la comunidad académica durante años hubiera sido otra cosa que ad
hoc. Alguien había escrito el primer RFC en un baño, por el amor de Dios. ARPA no solo nunca había encargado
oficialmente la serie RFC, sino que algunos de los RFC eran, literalmente, bromas.
Pero la comunidad de Internet (personas como Cerf, Kahn y Postel, que habían pasado años trabajando en TCP/
IP) se opuso al modelo OSI desde el principio. Primero estaban las diferencias técnicas, la principal de ellas era
que OSI tenía un diseño más complicado y compartimentado. Y fue un diseño que nunca se intentó. En lo que
respecta a los usuarios de Internet, en realidad habían implementado TCP/IP varias veces, mientras que el
modelo OSI nunca había sido sometido a pruebas de uso diario y prueba y error.
De hecho, en lo que respecta a la comunidad de Internet, el modelo OSI no era más que una colección de
abstracciones. "Todo lo relacionado con OSI se describió de una manera muy abstracta y académica",
dijo Cerf. “El lenguaje que usaron fue increíblemente turgente. No podrías leer un documento OSI ni
aunque tu vida dependiera de ello”.
TCP/IP, por otra parte, refleja la experiencia. Estaba en funcionamiento en una red real. "Podríamos probar
cosas", dijo Cerf. “De hecho, nos sentimos obligados a probar cosas, porque al final no tenía sentido especificar
algo si no ibas a hacerlo.
constrúyelo. Tuvimos esta retroalimentación pragmática constante sobre si las cosas funcionaron o
no”.
Cerf y otros argumentaron que TCP/IP no podría haberse inventado en ningún otro lugar que no fuera
el mundo de la investigación colaborativa, que fue precisamente lo que lo hizo tan exitoso, mientras que
un camello como OSI no podría haberse inventado en ningún otro lugar que no fuera en mil comités.
Quizás lo más importante es que el Departamento de Defensa ya había anunciado su elección de TCP e
IP como protocolos que se ejecutarían en las computadoras militares.
Las reuniones de ISO, que a menudo se celebraban en el extranjero en los años 1980, fueron en
ocasiones experiencias dolorosas para personas como Cerf y Postel. Los atendieron sólo para sentirse
como el rey Canuto gritándole a la marea entrante. “Yo era el tipo que siempre escribía el contrapunto”,
recuerda Cerf.
Si alguien podía atribuirse el mérito de haber trabajado incansablemente para promover TCP/IP, ese era Cerf.
La magia de Internet era que sus computadoras utilizaban un protocolo de comunicación muy simple. Y
la magia de Vint Cerf, comentó una vez un colega, fue que engatusó, negoció e instó a las comunidades de
usuarios a adoptarlo.
Mientras estaba en MCI en 1983, construyendo lo que se convertiría en MCI Mail, Cerf intentó que IBM,
Digital y HewlettPackard soportaran TCP/IP, pero se negaron y adoptaron OSI en su lugar. Digital,
en particular, había invertido mucho dinero en su red DECNET, basada en OSI. TCP/IP, argumentaron, era
"una cuestión de investigación". Cerf se sintió decepcionado y un poco molesto. “Dijeron que no iban a
fabricar productos con él. Así que tuve que crear MCI Mail a partir del desayuno de protocolos de un perro”.
Cerf unió MCI Mail a partir de protocolos existentes que estaban siendo utilizados internamente por
Digital e IBM, y desarrolló algunos más específicamente para MCI Mail. “Entendí por qué tomaron esa
posición, pero aun así me molestó”.
El interruptor
El 1 de enero de 1983, ARPANET iba a hacer su transición oficial a TCP/IP.
Se suponía que todos los usuarios de ARPANET habían realizado el cambio del protocolo de control de red
a TCP/IP. Ese día, el protocolo que había gobernado ARPANET quedaría inactivo, de modo que sólo
aquellas máquinas que ejecutaran los nuevos protocolos podrían comunicarse a través de la red. Algunos
sitios que aún no habían hecho la transición presentaron su caso ante Postel o su colega Dan Lynch, o
ante Bob Kahn, quien estaba supervisando la transición, y generalmente obtenían un período de gracia.
Pero en la primavera de 1983, o habías hecho la conversión o tu máquina se desconectaba de la red.
En términos de hitos, la transición a TCP/IP fue quizás el evento más importante que tendría lugar en el
desarrollo de Internet en los años venideros. Una vez instalado TCP/IP, la red podía ramificarse en cualquier
lugar; Los protocolos hicieron que la transmisión de datos de una red a otra fuera una tarea trivial. "Para
tomar prestada una frase", dijo Cerf, "ahora podría llegar a donde ninguna red había llegado antes". Ahora
existía una impresionante variedad de redes, desde ARPANET hasta TELENET y las Cícladas. De
hecho, eran tantos que
En un intento de imponer algo de orden, Jon Postel emitió un RFC asignando números a las redes.
En 1983, la Agencia de Comunicaciones de Defensa decidió que ARPANET había crecido lo

suficiente como para que la seguridad fuera ahora una preocupación. La agencia dividió la red en
dos partes: MILNET, para sitios que contienen información militar no clasificada, y
ARPANET para la comunidad de investigación informática. Antes de la división, había 113 nodos
en la red combinada. Después, 45 nodos permanecieron en ARPANET y el resto pasó a MILNET.
Administrativamente y operativamente había dos redes diferentes, pero los usuarios no podían
distinguir las puertas de enlace que las conectaban. La antigua ARPANET se había convertido en una
Internet en toda regla.
En 1988, cinco años después de la transición de ARPANET a TCP/IP en 1983, la ISO

finalmente produjo estándares para la interconexión de sistemas abiertos y el gobierno de
Estados Unidos adoptó inmediatamente los protocolos rivales OSI como su estándar oficial. Parecía
que OSI podría prevalecer sobre TCP/IP. En Europa, donde los gobiernos nacionales decretan las
normas, parecía un artículo de fe que OSI era la solución.
Por otro lado, la cultura estadounidense de Internet estaba creciendo exponencialmente y su base era
TCP/IP. Y mientras los gobiernos de toda Europa ungían a OSI, surgió una especie de movimiento
clandestino en las universidades europeas para implementar TCP/IP.
Un avance clave para determinar el resultado entre TCP/IP y OSI resultó ser la popularidad del sistema
operativo UNIX, que había sido desarrollado en los Laboratorios Bell de AT&T en 1969.
A los programadores les gustaba UNIX por dos razones principales: su flexibilidad les permitía
adaptarlo a cualquier programa en el que estuvieran trabajando y era "portátil", lo que significaba
que podía funcionar en muchas computadoras diferentes. A finales de la década de 1970, los
programadores de Berkeley desarrollaron su propia marca de UNIX y sembraron con ella la comunidad informática.
BerkeleyUNIX finalmente se convirtió en un elemento habitual en universidades e instituciones de
investigación de todo el mundo. Alrededor de 1981, Bill Joy, un hacker de UNIX en Berkeley, obtuvo
financiación ARPA para escribir TCP/IP en una versión de Berkeley UNIX. BBN ya había escrito
una versión de UNIX con TCP/IP, pero a Joy no le gustó y decidió hacerlo a su manera.
Luego, en 1982, Joy se unió a un par de graduados de la Escuela de Negocios de Stanford que
estaban iniciando una nueva empresa para construir y vender poderosas “estaciones de trabajo”,
computadoras que eran de un orden de magnitud más poderosas que las computadoras personales.
Joy fue incorporada como experta en UNIX. Llamaron a su empresa Sun (por Stanford University Network)
Microsistemas. Las primeras máquinas Sun se enviaron con la versión Berkeley de UNIX, completa
con TCP/IP. BerkeleyUNIX con TCP/IP sería crucial para el crecimiento de Internet. Cuando Sun incluyó
software de red como parte de cada máquina que vendió y no cobró por separado, las redes explotaron.
Se multiplicó aún más gracias a Ethernet.

Si bien la radio por paquetes y SATNET despertaron la idea de un marco conceptual para la interconexión de
redes, fueron en gran medida experimentales. Ethernet (la red de área local diseñada por Bob Metcalfe y
sus colegas en Xerox PARC allá por 1973) fue una solución práctica al problema de cómo conectar
computadoras entre sí, ya sea en un campus o en una empresa. Xerox comenzó a vender Ethernet como producto
comercial en 1980. Aproximadamente al mismo tiempo, la división de Bob Taylor en Xerox PARC otorgó una
subvención a importantes universidades de investigación en forma de equipos Ethernet, potentes
computadoras e impresoras láser. Ascendió a millones de dólares en hardware. Luego, una pequeña empresa de
redes llamada UngermannBass vendió Ethernet como conexión entre terminales y computadoras host. Y
Metcalfe fundó su propia empresa, 3Com, para vender Ethernet para computadoras comerciales,
incluidas las máquinas Sun.
A principios de la década de 1980, las redes de área local estaban de moda. Cada universidad conectó sus
estaciones de trabajo a redes de área local. En lugar de conectarse a una única computadora grande, las
universidades querían conectar toda su red de área local (o LAN) a ARPANET.
Ethernet hizo esto posible. Las Ethernet eran simples y, en comparación con las líneas de 50 kilobits de
ARPANET, tremendamente poderosas. Su rápido crecimiento en la comunidad universitaria y de investigación
impulsó la demanda de interconexión de redes. Si toda su universidad no estaba conectada a ARPANET, CSNET
le brindó una manera de conectar una computadora en su universidad a ARPANET. Pero fue Ethernet la que
creó un enorme grupo de redes.
En las principales universidades de investigación habría una red de cientos de computadoras que podrían
comunicarse entre sí a través de una red Ethernet. Para enviar tráfico desde una Ethernet en, digamos, San
Diego, a otra Ethernet en Buffalo, lo envió a través de ARPANEThub. De esta manera, ARPANET fue la pieza
central de lo que se llamó ARPA Internet. Y durante la primera mitad de la década de 1980, ARPA Internet
parecía una estrella, con varias redes rodeando a ARPANET en el centro.
Quizás lo que más recomendaba TCP/IP era el hecho de que era infaliblemente “abierto”. Todo su diseño
fue un proceso abierto, que siguió un camino trazado por primera vez por Steve Crocker y el Network
Working Group y continuó en Internet.
ARPANET, y más tarde Internet, surgieron tanto de la disponibilidad gratuita de software y documentación
como de cualquier otra cosa. (Por el contrario, DECNET de Digital Equipment era una red
propietaria). Internet también admitía una amplia gama de tecnologías de red. Aunque las redes de satélite y
de radio por paquetes tenían una vida útil finita, ayudaron a abrir los ojos a los desarrolladores sobre la
necesidad de manejar una multitud de redes diferentes.
Reformar el correo electrónico
Los estándares TCP e IP no fueron la única renovación importante de las redes a principios de los años 1980.
Durante años, todos los programas de correo electrónico escritos para ARPANET habían dependido del
protocolo de transferencia de archivos original para que sirviera como barcaza para transportar el correo de un lado a otro.
Puede que haya sido un buen truco adjuntar los comandos de correo al protocolo de transferencia de archivos en
primero, pero el procesamiento del correo electrónico se había vuelto más complicado. En un mensaje
a sus colegas en la lista de correo de MsgGroup un día a finales de agosto de 1982, Postel dijo: "Si realmente
observas las especificaciones de FTP, verás que los comandos de correo son en realidad una especie de
verruga". Postel y muchos otros sintieron que era hora de crear un mecanismo de transferencia de correo
completamente independiente.
Dado que la red estaba sufriendo una reorganización masiva con el cambio a TCP/IP, éste parecía un
momento apropiado para lanzar el nuevo estándar. Postel y sus colegas lo llamaron protocolo simple de
transferencia de correo (SMTP). Aclaró las prácticas existentes y agregó algunas características de
control nuevas.
Al mismo tiempo, el crecimiento de la red generó un nuevo problema. "Cuando llegamos a unos dos mil
hosts, fue cuando las cosas realmente empezaron a desmoronarse", dijo Craig Partridge, programador de
BBN. "En lugar de tener una gran computadora central con veinte mil personas, de repente nos vimos
inundados de máquinas individuales".
Cada máquina host tenía un nombre de pila, "y todos querían llamarse Frodo".
recordó Perdiz.
Seleccionar a los Frodos de Internet no fue diferente a seleccionar a los Jones de Cleveland o los Smith de
Smithville. El lugar donde uno vivía, precisamente, era importante para diferenciar quién era. Durante años,
resolver esto fue uno de los problemas más problemáticos y complicados para Internet, hasta que
finalmente un grupo elaboró un esquema viable, llamado sistema de nombres de dominio o DNS.
El núcleo del equipo DNS estaba formado por Jon Postel y Paul Mockapetris de ISI, y Craig Partridge de
BBN. Pasaron tres meses trabajando en los detalles del nuevo esquema de direccionamiento y en noviembre
de 1983 presentaron dos RFC que describían el sistema de nombres de dominio.
"DNS supuso un cambio muy significativo en la forma en que pensábamos sobre la organización del
sistema", dijo Postel. La “ramificación de árboles” fue la metáfora rectora. Cada dirección tendría una estructura
jerárquica. Desde el tronco hasta las ramas y hacia las hojas, cada dirección incluiría niveles de información
que representan, en progresión, una parte más pequeña y específica de la dirección de red.
Pero eso desató un debate sobre la secuencia de la jerarquía; lo que debería ser primero o último. Postel y
otros finalmente se decidieron por un esquema de direccionamiento de específico a general. La comunidad
de Internet también discutió sobre cómo nombrar los dominios, retrasando cualquier implementación durante
aproximadamente un año. Algunos afirmaron, de manera poco convincente, que los nombres de
dominio deberían reflejar fuentes de financiación específicas: MIT, DARPA, por ejemplo.
Finalmente, un comité acordó siete dominios de “nivel superior”: edu, com, gov, mil, net, org e int. Ahora
podría haber siete Frodos: una computadora llamada Frodo en una universidad (edu), una en un sitio
gubernamental (gov), una empresa (com), un sitio militar (mil), una organización sin fines de lucro (org), un
servicio de red. proveedor (net), o una entidad de tratado internacional (int).
DARPA comenzó a presionar a la gente para que adoptara direcciones DNS en 1985. En enero de 1986
se celebró una gran cumbre en la costa oeste, que reunió a representantes de las principales redes. Cuando
terminó la cumbre, todos coincidieron en que sí, que realmente creían en el concepto de DNS. "Y sí, así es
como íbamos a hacerlo funcionar", recordó Partridge, "y sí, tenemos la tecnología para hacer que todo
funcione".
Tirando del enchufe

El primer indicio que Cerf tuvo de que Internet iba a ser adoptado por un mundo fuera de las comunidades
científica y académica llegó en 1989, cuando entró en la exposición de Interop, una feria comercial iniciada
por Dan Lynch en 1986 para promover la interconectividad a través de TCP/IP. En sus primeros años, a
Interop asistieron unos cientos de personas expertas en redes. En 1989, el espectáculo estaba
repleto de hombres y mujeres vestidos con trajes de negocios. "Fue una epifanía entrar a Interop y ver
la gran cantidad de dinero que se gasta en exhibiciones con enormes demostraciones organizadas", dijo
Cerf. "Me di cuenta, Dios mío, que la gente está gastando mucho dinero en esto". Los expositores tenían
nombres como Novell, Synoptics y Network General. "Comenzamos a mirar las estadísticas de la
red y nos dimos cuenta de que teníamos un cohete en nuestras manos". Durante años, Cerf había
visto Internet como un experimento exitoso y satisfactorio. En ocasiones había esperado que
Internet pudiera llegar a un mundo más amplio de usuarios. Ahora aquí había evidencia de que estaba
haciendo precisamente eso.
En ese momento, prácticamente todo el mundo usaba TCP/IP. Y en Europa había una infraestructura
cada vez mayor basada en TCP/IP. TCP/IP estaba tan extendido y tanta gente dependía de él, que
eliminarlo y empezar de nuevo parecía impensable. En virtud de su silencioso impulso, TCP/IP había
prevalecido sobre el estándar oficial OSI. Su éxito proporcionó una lección práctica sobre la tecnología
y cómo avanza. “Los estándares deberían descubrirse, no decretarse”, dijo un informático de la facción
TCP/IP. Pocas veces ha funcionado de otra manera.
A finales de la década de 1980, Internet ya no era una estrella con ARPANET como centro; era una malla,
muy parecida al propio ARPANET. El programa NSFNET había democratizado las redes como ni siquiera
CSNET lo había hecho. Ahora cualquier persona en un campus universitario con conexión a Internet
podría convertirse en usuario de Internet. NSFNET se estaba convirtiendo rápidamente en la columna
vertebral de Internet, funcionando en líneas que eran más de veinticinco veces más rápidas que las líneas
ARPANET. Los usuarios ahora podían elegir entre conectarse a ARPANET o a la red troncal NSFNET.
Muchos eligieron este último, no sólo por su velocidad sino porque era mucho más fácil conectarse
a.
A medida que se acercaba la década de 1990, la cantidad de computadoras en el mundo que estaban
conectadas entre sí a través de NSFNET superó con creces la cantidad de computadoras conectadas
entre sí a través de ARPANET. ARPANET era ahora sólo una de los cientos de redes de Internet
ARPA, y un dinosaurio, incapaz de evolucionar tan rápidamente como el resto de Internet.
Bob Kahn, el único defensor de las redes de DARPA que quedaba, había dejado la agencia en 1985
para formar la Corporación para Iniciativas de Investigación Nacional, una empresa sin fines de lucro
cuyo objetivo era fomentar la investigación y el desarrollo de una "infraestructura de información
nacional". Las personas que ahora dirigen DARPA no estaban particularmente interesadas en
establecer contactos. En su opinión, se habían resuelto todos los problemas interesantes. Además, la
agencia se distrajo con el programa Star Wars del presidente Ronald Reagan.
El propio ARPANET, cuyo funcionamiento le costó a ARPA 14 millones de dólares al año, parecía
artrítico al lado del NSFNET de mayor velocidad. La dirección de DARPA decidió que ARPANET
había dejado de ser útil. Ya era hora de cerrarlo.
Mark Pullen, director del programa DARPA que ahora dirigía el proyecto de red, recibió la tarea
de desmantelar ARPANET. Nunca quedó del todo claro exactamente quién dio la orden desde
los niveles más altos de DARPA. "Nadie quería ser el demonio que apagó ARPANET", dijo Pullen,
"así que me convertí en la fuente de la política".
El plan de Pullen era sacar sitios de ARPANET y ponerlos en la columna vertebral de NSFNET.
Fue difícil contarle a Bob Kahn sobre el plan para desmantelar la red. Kahn había contratado a
Pullen, y ahora Pullen hacía de verdugo. "Tenía la sensación de que él podría sentir que estaba
apagando su mayor logro", dijo Pullen. “Lo que pareció perjudicarle más fue cuando apagué el
antiguo SATNET”. SATNET era lento, caro y anticuado. “Sin duda debió haber sentido que era
su propio hijo. Por razones válidas. Pero después de pensarlo, estuvo de acuerdo en que estaba
haciendo lo correcto”. (Resultó que el dinero que DARPA ahorró al desactivar ARPANET ayudó
a financiar el nuevo proyecto de Kahn).
Uno por uno, Pullen apagó los IMP y TIP que aún se encontraban en el corazón de la red original.
Había cierta tristeza en su desaparición que recordaba la escena de 2001: Odisea en el espacio,
de Arthur C. Clarke, donde la computadora ficticia de quinta generación HAL amenaza su misión
y debe ser desmantelada circuito por circuito. A medida que HAL pierde gradualmente la
“mente”, hace llamamientos patéticos por su “vida” a Dave, el astronauta, que está desmantelando.
En el caso de ARPANET, la red murió pero sus piezas siguieron vivas. "No fue tan diferente de la
ruptura de Ma Bell", recordó Pullen. "Implicaba localizar grupos de sitios ARPANET y encontrar
a alguien que se hiciera cargo de ellos". En la mayoría de los casos, Pullen transfirió cada
sitio de ARPANET a una de las redes regionales y facilitó la transición subsidiando el costo por un
tiempo. Con excepción de dos sitios que pasaron a MILNET, todos los sitios pasaron a una
u otra de las redes regionales. “Nunca nadie se opuso tan ruidosamente”, dijo Pullen. "Creo que
todos sabían que había llegado el momento".
Un sitio a la vez, Pullen les encontró nuevos hogares. Donde no había un hogar, DARPA y
NSF ayudaron a crear uno. Varios sitios de ARPANET en el sur de California formaron
rápidamente su propia red regional y la llamaron Los Nettos; estaba dirigido por Danny Cohen y Jon
Postel. Los propios IMP fueron apagados, desconectados y enviados. La mayoría simplemente
fueron desechados. Otros entraron en servicio en MILNET. El Museo de la Computación
de Boston consiguió uno y Len Kleinrock exhibió el IMP Número Uno para los visitantes de la
UCLA. El último IMP en desaparecer fue el de la Universidad de Maryland. Por coincidencia,
Trusted Information Systems, una empresa de Maryland donde ahora trabajaba Steve Crocker,
estaba conectada a ese IMP. Crocker había estado allí en el nacimiento y estuvo allí en el momento
de la muerte.
A finales de 1989, ARPANET había desaparecido. La NSFNET y las redes regionales que había
generado se convirtieron en la columna vertebral principal. Ese año, para conmemorar el vigésimo
aniversario de ARPANET y su fallecimiento, la UCLA patrocinó un simposio y lo llamó "Acto Uno".
En su discurso, Danny Cohen encontró una fuente de inspiración y dijo lo siguiente:
“Al principio ARPA creó ARPANET.
“Y la ARPANET estaba desordenada y vacía.
“Y las tinieblas cubrieron el abismo.
“Y el espíritu de ARPA se movió sobre la superficie de la red y ARPA dijo: 'Que haya un protocolo', y
había un protocolo. Y ARPA vio que era bueno.
“Y ARPA dijo: 'Que haya más protocolos', y así fue. Y ARPA vio que era bueno.
“Y ARPA dijo: 'Que haya más redes', y así fue”.
Epílogo
septiembre de 1994
La fiesta fue idea de BBN: reunir a un par de docenas de actores clave en Boston y celebrar el vigésimo
quinto aniversario de la instalación del primer nodo ARPANET en UCLA. A estas alturas, Internet había
crecido mucho más allá de un experimento de investigación. A medida que más personas
descubrían su utilidad, se estaba convirtiendo en una palabra familiar. La Red prometía ser para el siglo
XXI lo que el teléfono había sido para el siglo XX. Su existencia ya estaba alcanzando casi todos
los aspectos de la cultura estadounidense, desde la publicación hasta la socialización. Para
muchos, el correo electrónico se ha convertido en una parte indispensable de la vida diaria. Las personas
mayores confinadas en casa lo utilizaban para encontrar compañía; algunas familias remotas lo utilizaron
como pegamento. Cada día más personas se conectaban para realizar negocios o encontrar entretenimiento en la Red.
Los analistas consideraron que Internet sería la próxima gran oportunidad de marketing.
El despegue apenas comenzaba. En 1990, investigadores del CERN, el Laboratorio Europeo de Física
de Partículas cerca de Ginebra, crearon la World Wide Web, una rama multimedia de Internet.
Utilizando el protocolo HTTP de Tim BernersLee, los científicos informáticos de todo el mundo
comenzaron a hacer que Internet fuera más fácil de navegar con programas de apuntar y hacer clic.
Estos navegadores se inspiraron en el original de BernersLee y, por lo general, se basaron en la
biblioteca de códigos del CERN. Un navegador en particular, llamado Mosaic, creado en 1993 por un
par de estudiantes de la Universidad de Illinois, ayudaría a popularizar la Web y, por tanto, la Red como
ninguna herramienta de software lo había hecho hasta ahora.
La Red de los años 70 hacía tiempo que había sido suplantada por algo a la vez más sofisticado
y más difícil de manejar. Sin embargo, en docenas de maneras, la Red de 1994 todavía reflejaba las
personalidades e inclinaciones de quienes la construyeron. Larry Roberts siguió sentando las bases de la
gran casa laberíntica que se convirtió en Internet. La actitud pragmática de Frank Heart hacia la
invención técnica: constrúyala, tírela a la red y repárela
si se rompe, impregnó la sensibilidad de la red durante años. La apertura en el proceso del protocolo comenzó
con el primer RFC de Steve Crocker para el Grupo de Trabajo de Red y continuó en Internet. Mientras estuvo
en DARPA, Bob Kahn tomó una decisión notoria de mantener la apertura. Vint Cerf le dio a la Red su civismo. Y
los creadores de la Red todavía dirigían la Internet Society y asistían a las reuniones del Internet Engineering Task
Force.
Justo cuando los planes del partido se pusieron en marcha, BBN consiguió un nuevo director ejecutivo. George
Conrades, un destacado veterano del marketing de IBM, había sido contratado por el presidente de BBN, Steve
Levy, para reformar los negocios de la empresa. A Conrades le encantó la idea de la fiesta.
Lo aprovechó como un vehículo de marketing perfecto. Conrades estaba enamorado del papel pionero de
BBN. Decidió que BBN era la empresa de Internet original, un reclamo de fama que la empresa aún tenía que
explotar. Haz que la fiesta sea grande y lujosa. Alquile el hotel Copley Plaza.
Celebre a los pioneros de la red como si hubieran sido los primeros en pisar la superficie de la luna.
Invite a luminarias de la industria informática. E invitar a la prensa.
BBN necesitaba el impulso. A lo largo de la década de 1980, la fortuna de la empresa había decaído en gran medida.
A medida que Internet se hizo más popular, BBN, que una y otra vez no había logrado comercializar sus
esfuerzos de investigación, había caído en una relativa oscuridad. En 1993, la empresa perdió 32 millones de
dólares sobre 233 millones de dólares en ventas. El año siguiente no fue mucho mejor, con una pérdida de 8
millones de dólares por menores ventas.
La empresa había perdido su mayor oportunidad cuando no logró ingresar al mercado de enrutadores, del cual
los IMP fueron los progenitores. BBN no vio el potencial de los enrutadores, del mismo modo que AT&T se negó a
reconocer la conmutación de paquetes. Cualquiera que quisiera conectar una red de área local (de la que
ahora había cientos de miles) a Internet necesitaba un enrutador. En 1994, el negocio de los enrutadores era una
industria multimillonaria.
Más de una década antes, un par de informáticos de BBN habían intentado empujar a la empresa al negocio de
los enrutadores, pero un vicepresidente de marketing los había desestimado.
Los problemas de BBN fueron más allá de las oportunidades de mercado fallidas. En 1980, el gobierno federal acusó
a la empresa de conspirar para cobrar de más al gobierno en sus contratos durante el período de 1972 a 1978, y de
alterar las hojas de horas para ocultar los sobrecargos. La práctica se descubrió cuando, en el curso de una auditoría
de rutina a fines de la década de 1970, los funcionarios del BBN fueron poco sinceros con un auditor del
gobierno. (“BBN se había vuelto muy arrogante”, dijo un empleado de mucho tiempo). Una investigación
federal duró más de dos años. Los auditores se trasladaron a la sede de la empresa en Cambridge. Los altos
empleados de BBN fueron citados ante un gran jurado. Ninguno de los tipos IMP estuvo implicado. Pero en 1980,
dos de los funcionarios financieros de alto rango de la compañía lograron salir de un cargo de cien cargos. Se les
impuso sentencia suspendida y una multa de 20.000 dólares cada uno.
La empresa acordó pagar una multa de 700.000 dólares.
En ese momento, BBN dependía de contratos gubernamentales para casi el 80 por ciento de sus ingresos.
Dada la certeza de que todas las adjudicaciones de contratos gubernamentales a BBN habrían sido
suspendidas durante el transcurso de cualquier larga defensa legal, si no se hubiera llegado a un acuerdo, los cargos
podrían haber arruinado a la empresa. La gente de la empresa sintió que el gobierno había reaccionado
exageradamente ante las prácticas contables incorrectas. BBN, dijeron, tenía
siempre le ha dado al gobierno federal mucho más de lo que vale su dinero en I+D por contrato.
El grupo de trabajo en red de la BBN, que apenas participó en la investigación gubernamental, ofreció al mismo
tiempo pruebas positivas de que la ciencia financiada por el gobierno puede dar espléndidos frutos. ARPANET
fue la prueba A. Financiada íntegramente por ARPA, y a sus creadores se les dio rienda suelta razonablemente
libre, la red era evidencia de una confianza estadounidense en la ciencia que alguna vez fue generalizada. La red
se construyó en una época en la que Washington brindaba un poco de orientación y mucha fe.
En 1994, los roces del BBN con los auditores gubernamentales habían quedado olvidados. Desafortunadamente,
también lo fue el papel de la empresa en la construcción de ARPANET. Sólo aquellos conocedores de la
historia asociaron la empresa con el nuevo Internet popular. Cuando llegó Conrades, decidió que era hora de
pulir la imagen de BBN. Y una fiesta de aniversario de plata para ARPANET fue la oportunidad
perfecta.
La lista de invitados a la fiesta fue tan examinada como la lista de invitados a una cena en la Casa Blanca. Algunos
nombres eran obvios, por supuesto; pero decenas de personas habían colaborado en la construcción de
ARPANET, y aún más personas, de todo el mundo, habían participado en Internet. Heart, Walden y otros
presentaron sugerencias. Fue invitado el vicepresidente Al Gore, defensor de la superautopista de la
información. También Ed Markey, un congresista demócrata de Massachusetts que también había incluido Internet
en su agenda política; aceptó la invitación. Bill Gates fue invitado, aunque el presidente de Microsoft aún no había
reconocido que Internet era una herramienta útil. Él se negó.
Paul Baran, cuyo papel fue minimizado en BBN, casi no fue invitado en absoluto. Con el tiempo, la lista aumentó
a quinientos invitados.
Conrades quería que esto fuera tanto una señal para el futuro como una celebración del pasado. Estaba planeando
que BBN ampliara su papel algo disminuido en los negocios relacionados con Internet. BBN ya poseía y
operaba NEARnet, la red regional de Nueva Inglaterra. Uno de sus primeros pasos después de llegar fue
comprar BARRnet, la red regional en el Área de la Bahía de San Francisco. Y tenía el ojo puesto en SURAnet,
la red regional del Sudeste.
Buscando un tema elevado, la firma de relaciones públicas que BBN contrató para aumentar su propio
departamento de relaciones públicas ideó uno: "Historia del futuro". Se adaptaba perfectamente a los planes
de Conrades para BBN. Conrades también contrató a una productora para preparar una elaborada presentación
en video que incluiría entrevistas con un grupo central de pioneros: Larry Roberts, Bob Kahn, Steve Crocker,
Len Kleinrock, Frank Heart y Vint Cerf.
Bob Metcalfe, el inventor de Ethernet, era ahora editor de un periódico especializado en informática
llamado InfoWorld. Escribió una columna de opinión sobre el próximo evento que tituló: “Viejos locos se disputarán
el crédito en el 25º aniversario de Internet”. “Estaré allí para ver a viejos amigos, para renovar algunas viejas
animosidades y para unirme a la lucha por el crédito...
de los cuales hay mucho para todos”, escribió Metcalfe. “Comenzaré asegurándome de que los asistentes
a la fiesta se den cuenta de que la mayor parte del tráfico TCP/IP se realiza a través de Ethernet, que inventé yo. . .
A medida que la fiesta llegue a su punto máximo, veré cuánto crédito puedo obtener de Vint Cerf y Bob Kahn por el
invención de la interconexión de redes. . . De lo contrario, veré si puedo aparecer con una sonrisa en la foto
grupal de los inventores de la conmutación de paquetes”.
Semanas y días antes del evento, la firma de relaciones públicas de BBN publicó historias en
revistas y periódicos. Newsweek publicó un artículo extenso sobre los pioneros de ARPANET, al igual que el
Boston Globe. BBN preparó un videoclip de noticias, que se transmitió en más de cien noticieros locales.
Ray Tomlinson, cuyo escrutinio de su teclado en un momento oportuno había producido el signo @, fue
celebrado como un héroe popular en una historia transmitida por la Radio Pública Nacional la noche de
la fiesta.
Los invitados de honor comenzaron a llegar el viernes 9 de septiembre y se reunieron para una recepción
seguida de una conferencia de prensa en Copley Plaza esa tarde. A modo de broma, Wes Clark, ahora
consultor en Nueva York, colocó la placa con el nombre de Larry Roberts en su propia chaqueta deportiva.
En la conferencia de prensa, varios de los pioneros de ARPANET, que superaban en número a los
periodistas, pronunciaron discursos. En su discurso, Bob Taylor comentó con ironía que las personas que
habían sido invitadas habían enviado a sus abuelos.
La ausencia más destacada fue la de Licklider, fallecido en 1990, pero su esposa, Louise, aceptó la
invitación. Bernie Cosell, el experto en depuración del equipo IMP, que ahora vivía en la Virginia rural y
criaba ovejas (“Demasiada gente, muy pocas ovejas”, se lee en la firma del correo electrónico de Cosell), no
pudo venir debido al gasto. Otros se negaron. Will Crowther, famoso por su aversión a las fiestas, rechazó la
invitación; Las repetidas llamadas telefónicas de otros chicos de IMP no pudieron hacerle cambiar de
opinión.
En un buffet mexicano después de la conferencia de prensa, todos se mezclaron. Algunas personas se

habían visto unos días antes, o unos meses antes, pero otras no se habían visto en años, o incluso décadas.
Se comentaba tranquilamente sobre los nuevos cónyuges, los antiguos cónyuges y el envejecimiento
prematuro. Larry Roberts, que ahora dirigía una pequeña empresa que estaba construyendo una nueva
generación de conmutadores, vivía en Woodside, California, una comunidad acomodada en la
península de San Francisco. Roberts, que ahora tenía cincuenta y ocho años, seguía un régimen diario
de “drogas inteligentes” (una de ellas era el Deprenyl, utilizado para tratar el Parkinson; otra, la melatonina)
para recuperar la capacidad de concentración que poseía a los veintiocho años. Con su característica
intensidad, se sumergió en el tema. Leyó cientos de informes de investigación e incluso produjo una cinta
de vídeo “antienvejecimiento”.
En 1983, Taylor había abandonado el Centro de Investigación de Palo Alto de Xerox. Su partida provocó una
serie de renuncias de investigadores leales, que lo siguieron hasta Digital Equipment Corp., donde
instaló un laboratorio de investigación a sólo unas pocas millas de Xerox PARC. Durante años vivió a la
vuelta de la esquina de Larry Roberts y ninguno de los dos lo sabía. Un día, un correo dirigido a Lawrence G.
Roberts fue entregado mal en la casa de Taylor y los dos descubrieron que vivían a unos cientos de metros
de distancia.
El segundo día de la fiesta de BBN, el sábado por la mañana, llegaron las sesiones de fotos, una tras otra.
Primero fue la foto grupal oficial. El grupo era numeroso, unas veinticinco personas. Cuando Len Kleinrock
se perdió la primera sesión de fotos oficial, hubo que organizar otra. Para otra pose, se pidió al grupo
principal de IMP Guys que posaran exactamente como en la foto original de IMP Guys tomada en 1969.
“¿Podrían ustedes perder algo de peso?” Cerf gritó mientras el fotógrafo intentaba colocar a todos en la
toma.
Después, los científicos fueron trasladados en autobús a dos cuadras del Christian Science Center para
una sesión fotográfica para la revista Wired. Valientemente, los diecinueve hombres se apretujaron
en un puente corto y estrecho en el Mapparium del Centro. Como ingenieros, no pudieron evitar ofrecerle
un consejo al fotógrafo, que estaba teniendo problemas para encajarlos a todos en la toma: pruebe con
un ángulo diferente. Pruebe una configuración diferente. Pruebe con una lente diferente. Pruebe
con una cámara diferente. Más tarde, algunos miembros del grupo se quejaron de que los parásitos
habían aparecido para la foto, pero en su mayor parte, el buen humor general del fin de semana estaba
empezando a contagiarlos a todos.
Los múltiples reclamos de paternidad en Internet (no sólo cada hombre había estado allí desde el
principio sino que cada uno había hecho una contribución que consideraba inconmensurable) salieron a
la luz de manera más notoria esa tarde durante una entrevista grupal con Associated Press. La
entrevista se realizó a través de un altavoz en una suite del hotel. Kahn, Heart, Engelbart y Kleinrock
estaban sentados encorvados frente al teléfono mientras el periodista de AP hacía preguntas. En poco
tiempo, la entrevista se transformó en un estudio sobre gestión de crédito. Taylor llegó tarde, pero no
demasiado tarde para involucrarse en una especie de polémica con Bob Kahn, quien advirtió al
periodista de AP que se asegurara de distinguir entre los primeros días de ARPANET e Internet, y
que fue la invención de TCP/IP lo que marcó los verdaderos inicios de la interconexión de redes.
No es cierto, dijo Taylor. Las raíces de Internet sin duda se encuentran en ARPANET. El grupo que
rodeaba el teléfono se sintió incómodo. “¿Qué hay de las mujeres?” preguntó el periodista, tal vez
para romper el silencio. “¿Hay mujeres pioneras?” Más silencio.
El fin de semana fue tan notable por los que no estuvieron presentes como por los que sí. Tim Berners
Lee, el inventor de la World Wide Web, acababa de mudarse a Boston desde Ginebra para unirse al
Laboratorio de Ciencias de la Computación del MIT. No fue invitado, ni Marc Andreessen, el
coprogramador de Mosaic, que acababa de dejar Illinois para desarrollar una versión comercial de su
navegador web. Por supuesto, no habían desempeñado ningún papel en el nacimiento
de ARPANET ni de Internet (Andreessen ni siquiera nació hasta 1972, después de que se
instalaran los primeros nodos de ARPANET) y técnicamente no podían ser contados como fundadores.
Pero ellos estaban detrás de los dos inventos que ya estaban dando a la Red su mayor alcance en
la vida cotidiana.
Tres años antes, la NSF había levantado las restricciones contra el uso comercial de Internet, y ahora uno
podía hacerse rico no sólo inventando una puerta de entrada a la Red, sino llevando los propios
negocios a la Red. Cuando los periodistas les pidieron que comentaran sobre esto, algunos de los
creadores originales de ARPANET dijeron que encontraban lamentable la nueva comercialización
de la Red. Otros lo acogieron con agrado.
Pocos de los pioneros se habían hecho ricos. La invención de Ethernet por parte de Metcalfe lo había
convertido en multimillonario. En sus casi treinta años como profesor de informática en UCLA, Kleinrock
había guiado a un ejército de doctores. estudiantes, muchos de los cuales se convirtieron en
luminarias en el campo de las redes informáticas. Aún enseñando en UCLA, Kleinrock dirigió un exitoso
negocio de seminarios. Pero en el otro extremo del espectro estaba Jon Postel, el héroe anónimo del
networking. Observó tranquilamente el fin de semana de celebración, del mismo modo que había
trabajado durante años como guardián de los RFC y árbitro final en las cuestiones técnicas.
importa cuando no se puede llegar a un consenso. Postel creía que las decisiones que había tomado
en el curso de su trabajo a lo largo de los años habían sido por el bien de la comunidad, y que iniciar
una empresa para beneficiarse de esas actividades habría equivalido a una violación de la confianza
pública.
La mayoría de los chicos de IMP habían terminado en la alta dirección de BBN. Más tarde, Walden se
desempeñó como jefe de Heart y Barker pasó a dirigir una de las divisiones de BBN. La
excepción más notoria a esto fue Crowther, que seguía siendo programador. Durante años, Heart había
sido el defensor de Crowther, presionando para que la empresa dejara que Crowther fuera simplemente
Crowther y pensara ideas ingeniosas a su manera soñadora. En los años posteriores al proyecto IMP,
Crowther persiguió algunas ideas inusuales sobre el procesamiento del lenguaje natural y trabajó
extensamente en tecnología de conmutación de paquetes de alta velocidad.
Severo Ornstein había dejado BBN en la década de 1970 por Xerox PARC, y mientras estaba allí
fundó Computer Professionals for Social Responsibility. Cuando se retiró de Xerox, él y su esposa se
mudaron a uno de los rincones más remotos del área de la Bahía de San Francisco. Durante años,
Ornstein se mantuvo alejado de la red y durante años evitó el correo electrónico.
De todos, Vint Cerf fue quizás el más celebrado este fin de semana. Era la persona a la que acudía la
mayoría de la prensa en busca de citas sobre los orígenes de Internet. A principios de 1994 dejó la
Corporación de Iniciativas Nacionales de Investigación de Kahn para regresar a MCI como
vicepresidente senior y ayudar a desarrollar los negocios de Internet de la empresa. Su reputación
era bien conocida en toda la empresa. En un centro de operaciones de MCI en Carolina del Norte
alguien había colgado un cartel: "¡Vint Cerf es el padre de Internet, pero nosotras somos las madres
que tenemos que hacer que funcione!".
A medida que se acercaba la cena del sábado, hubo una gran prisa de último minuto para asegurarse
de que el guión de la velada tuviera el tono adecuado. Conrades iba a ser el maestro de ceremonias
del evento principal. Nadie debería recibir poca atención a expensas de los demás. Era una tarea
casi imposible. En el último momento se volvió a cambiar la asignación de asientos.
Cuando finalmente comenzó la cena, unas 250 personas llenaron el gran salón de baile.
Al presionar a favor de un proyecto de ley de telecomunicaciones que estaba pendiente, el congresista
Markey pronunció un discurso humorístico. Cerf presentó dos premios y Kahn fue destacado por los
logros de su vida. Louise Licklider, frágil y anciana, se puso de pie para recibir un largo aplauso en
nombre de su difunto esposo.
La celebración tuvo un significado especial para Heart, que ahora tiene sesenta y cinco años,
quien recientemente se había retirado como presidente de la División de Tecnología y Sistemas de BBN.
Llevaba veintiocho años en BBN. Steve Levy, presidente de BBN, llamó a Heart al podio y Heart
pronunció un discurso en el que señaló las razones por las que el proyecto ARPANET había
tenido éxito. "El proyecto fue un ejemplo de lo que se puede lograr rápidamente, con un liderazgo
realmente fuerte y sofisticado, recursos adecuados y evitando los muchos tipos de tonterías burocráticas
que pueden afectar a tantos proyectos". Roberts se había ocupado de eso. El corazón terminó con
una nota alta. "Sólo una pequeña fracción de la población técnicamente capacitada tiene la
oportunidad de montar un cohete tecnológico y luego ver cómo la revolución cambia el mundo". La
revolución de las redes, afirmó Heart, figuraría entre una pequeña
algunos de los cambios tecnológicos más importantes del siglo. Y esa noche, en esa habitación,
parecía que podría tener razón.
A la mañana siguiente, uno por uno, los pioneros de ARPANET se despidieron y abandonaron el hotel.
Todo el mundo todavía estaba en lo alto, al menos un poco. No habían sido un mal par de días.
Notas del capítulo

Capítulo uno
La descripción de la formación de la Agencia de Proyectos de Investigación Avanzada y su Oficina
de Técnicas de Procesamiento de Información se deriva de entrevistas personales, dos libros
escritos por el asesor científico de Eisenhower, James Killian (ver bibliografía), artículos de
revistas y de una excelente y exhaustiva historia de la agencia. encargado por DARPA y
escrito por Richard J. Barber Associates en 1975. La descripción de los primeros años de Licklider
se basa en charlas dadas en su honor, en entrevistas con Louise Licklider y Bill McGill, y en un obituario
escrito por Karl D. Kryter. La descripción de la introducción de Licklider a las computadoras se basa en
entrevistas personales con Wes Clark y Jack Ruina, y en la entrevista de Licklider con el Instituto Charles
Babbage, así como en el informe de Barber Associates.
Capitulo dos
La descripción del trabajo de Paul Baran sobre comunicaciones distribuidas se basa en entrevistas
personales con Baran, así como en varias entrevistas realizadas por el Instituto Babbage.
La descripción de los primeros trabajos de Donald Davies sobre conmutación de paquetes se
basa en entrevistas y correspondencia con Donald Davies, y en los artículos y entrevistas de Martin
CampbellKelly. El impresionante informe de Arthur Norberg y Judy O'Neill, “Una historia de la Oficina
de Técnicas de Procesamiento de Información de la Agencia de Proyectos de Investigación
Avanzada de Defensa” también nos guió a través del material biográfico y de los primeros años de
la IPTO. El informe sirvió de base para su libro Transforming Computer Technology: Information
Processing for the Pentagon,1962–1986 (Johns Hopkins University Press, 1996).
Paul Baran y el profesor Manley Irwin proporcionaron información sobre las demandas de AT&T
contra partes que se cree que están privando a AT&T de ingresos.
La patente de Doug Engelbart para su ratón llegó el 17 de noviembre de 1970. Es la patente

número 3.541.541.
Capítulo tres
La historia de Bolt Beranek y Newman se basó en entrevistas personales con Dick Bolt y Leo
Beranek. La descripción del Laboratorio Lincoln se basó en entrevistas con Wes Clark, Frank
Heart, Larry Roberts y Len Kleinrock. La descripción de los acontecimientos que rodearon
la solicitud de propuestas para el Procesador de mensajes de interfaz se basó en entrevistas
con Jerome Elkind, Frank Heart, Dave Walden y Severo Ornstein, así como en varias entrevistas
realizadas por el Instituto Charles Babbage.
Capítulo cuatro
La descripción de la construcción del procesador de mensajes de interfaz se basó en
entrevistas con Dave Walden, Ben Barker, Severo Ornstein, Bob Kahn, Frank Heart, Alex
McKenzie y Will Crowther. También nos basamos en la solicitud de propuestas de ARPA y en la
propuesta de BBN.
Capítulo Cinco
La descripción de los preparativos de UCLA y la recepción del IMP Número Uno se basa en
entrevistas con Len Kleinrock, Steve Crocker, Mike Wingfield y Vint Cerf. La descripción de
los primeros trabajos del Network Working Group en protocolos en capas se basó en
entrevistas con Steve Crocker, Jon Postel y Vint Cerf. La descripción de la primera sesión de
inicio de sesión entre UCLA y SRI se basó en entrevistas con Len Kleinrock y Charley Kline.
La descripción de las pruebas de estancamiento realizadas a principios de 1970 se basó en
entrevistas con Bob Kahn, Dave Walden y Vint Cerf.
John Melvin nos ayudó en nuestra infructuosa búsqueda de quien podría haber estado al
otro lado de la sesión inicial de inicio de sesión entre UCLA y SRI. Ahora sabemos quién no
fue. Todavía estamos ansiosos por saber quién fue.
Capítulo Seis
La descripción de los primeros sitios ARPANET se basó en informes técnicos trimestrales,
artículos técnicos y entrevistas de BBN con John Melvin y John Day. Alex McKenzie
proporcionó información sobre los primeros días del Centro de operaciones de red. La
descripción de los problemas de mantenimiento del IMP y su posterior resolución se basó en
entrevistas con Ben Barker, Frank Heart, Severo Ornstein y Alex McKenzie. La descripción
de la demostración de ARPANET en ICCC '72 se basó en entrevistas con Al Vezza, Bob
Kahn, Steve Crocker, Len Kleinrock, Jon Postel, Alex McKenzie y Larry Roberts. “PARRY
Encounters the Doctor” se publicó en su totalidad como un RFC y apareció en la revista
Datamation en julio de 1973.
Capítulo Siete
La descripción del truco de correo electrónico original de Ray Tomlinson y su elección del signo @ como
separador (y como problema para los usuarios de UNIX) se basó en entrevistas con Tomlinson y JohnVittal.
Ed Vielmetti nos envió por primera vez partes de los archivos de MsgGroup. Einar Stefferud los salvó
a todos y los depositó en el Museo de la Computación de Boston. Ken Harrenstien nos ayudó a aclarar
algunos de los primeros antecedentes de las listas de correo. Ned Freed nos proporcionó cifras
comparativas sobre el uso del correo electrónico.
La descripción de los orígenes de Adventure se basó en entrevistas con Don Woods, Will Crowther y
Dave Walden. Los recuerdos de Woods sobre aventuras también aparecen en The Unix Book of Games,
de Janice Winsor, PrenticeHall Computer Books, 1996.
Las observaciones de la página 208 sobre las proclamaciones de oficialidad en la Red provienen de
“How Anarchy Works”, de Paulina Borsook, revista Wired, octubre de 1995. La historia del programa
Finger proviene de Les Earnest.
Capítulo Ocho
Las descripciones de los programas de radio por paquetes y por satélite se basaron en varios artículos
técnicos (ver bibliografía), así como en entrevistas personales con Vint Cerf, Alex McKenzie y Bob Kahn.
Parte del material fue tomado de entrevistas realizadas por el Instituto Charles Babbage. La descripción
de la evolución de TCP/IP se basó en entrevistas con Vint Cerf, Bob Kahn, John Shoch, Alex
McKenzie y Jon Postel.
La descripción de los orígenes de Ethernet se basó en entrevistas con Bob Metcalfe.

La descripción de Ethernet que hace Butler Lampson está tomada de Fumbling the Future, de Douglas
Smith y Robert C. Alexander (William Morrow, 1988), p. 97.
Artículo de Ole Jacobsen, “El problema con OSI”, ConneXions, volumen 6, no. 5 de mayo de 1992,
particularmente la referencia a las baterías doble AA, ayudó a guiar la sección sobre OSI vs.
TCP/IP. El libro de Peter Salus Casting the Net (AddisonWesley, 1995) y su artículo “Protocol Wars:
Is OSI Finalmente Dead?” en ConneXions, volumen 9, núm. El 8 de agosto de 1995 también ayudó a
encuadrar el debate.
Danny Cohen nos dio permiso para editar ligeramente y reimprimir el poema que leyó ante los
reunidos en el Simposio Act One en UCLA en 1989.
Bibliografía
Libros
Alexander, Charles C.Manteniendo la línea: la era Eisenhower, 19521961. Bloomington: Indiana
University Press, 1975.
Baran, Paul. "Conmutación de paquetes". EnFundamentos de la conmutación digital.2d ed. Editado

por John C. McDonald. Nueva York: Plenum Press, 1990.
Barry, John A. Technobabble. Cambridge: MIT Press, 1991.
Bell, C. Gordon, Alan Kotok, Thomas N. Hastings y Richard Hill. "La evolución del sistema DEC10".
En Ingeniería informática: una visión DEC del diseño de sistemas de hardware. Editado por
C. Gordon Bell, J. Craig Mudge y John E. McNamara. Bedford, Massachusetts: Digital Equipment
Corporation, 1978.
Bell, C. Gordon, Gerald Butler, Robert Gray, John E. McNamara, Donald Vonada y Ronald Wilson.
"El PDP1 y otras computadoras de 18 bits". En Ingeniería informática: una visión de DEC del
diseño de sistemas de hardware. Editado por C. Gordon Bell, J. Craig Mudge y John E. McNamara.
Bedford, Massachusetts: Digital Equipment Corporation, 1978.
Bergaust, Erik. Wernher von Braun. Washington, DC: Instituto Nacional del Espacio, 1976.
Blanc, Robert P. e Ira W. Cotton, eds.Computer Networking. Nueva York: IEEE Press, 1976.
Brendon, Piers. Ike: His Life and Times. Nueva York: Harper & Row, 1986.
Brooks, John. Teléfono: Los primeros cien años. Nueva York: Harper & Row, 1976.
Brucker, Roger W. y Richard A. Watson. La cueva más larga. Nueva York: Alfred A.
Knopf, 1976.
Clarke, Arthur C. y otros. El primer siglo del teléfono y más allá: ensayos con motivo del
centenario de la comunicación telefónica. Nueva York: Thomas Y.
Compañía Crowell, 1977
Informática, Análisis Numérico y Computación. Laboratorio Nacional de Física, Grupo de Ciencias

de la Ingeniería, Investigación 1971. Londres: Oficina de Papelería de Su Majestad, 1972.
Froehlich, Fritz E., Allen Kent y Carolyn M. Hall, eds. "ARPANET, la red de datos de defensa e
Internet". En The Froehlich/Kent Encyclopedia of Telecommunications. Nueva York: Marcel Dekker,
Inc., 1991.
Goldstein, Jack SA Diferentes tipos de tiempo: la vida de Jerrold R. Zacharias. Cambridge MIT
Press, 1992.
Halberstam, David. The Fifties. Nueva York: Villard Books, 1993.
Hall, Mark y John Barry. Sunburst: The Ascent of Sun Microsystems. Chicago:
Contemporary Books, 1990.
Hammond, William M.Asuntos públicos: los militares y los medios de comunicación, 1962–
1968.Washington, DC: Centro de Historia Militar, Ejército de EE. UU., Superintendente de
Documentos, Imprenta del Gobierno de EE. UU., 1968.
Hamner, W. Arcilla. “El Servicio Postal de los Estados Unidos: ¿Estará listo para el año 2000?” En El
futuro del servicio postal. Editado por Joel L. Fleishman. Nueva York: Praeger, 1983.
Holzmann, Gerard J. y Björn Pehrson. The Early History of Data Network. Los Alamitos, California:
IEEE Computer Society Press, 1995.
Kidder, Tracy. El alma de una nueva máquina. Boston: Little, Brown, 1981.
Killian, James R., Jr. Sputnik, Scientists, and Eisenhower: Memorias del primer asistente especial del
presidente para ciencia y tecnología. Cambridge: MIT Press, 1977.
———La educación de un presidente universitario: una memoria. Cambridge: MIT Press, 1985.
Kleinrock, Leonard. Redes de comunicación: retraso y flujo de mensajes estocásticos. Nueva York:
McGrawHill, 1964.
———Sistemas de colas.2 vols. Nueva York: John Wiley & Sons, 1974–1976.
LangdonDavies, John. NPL: Jubilee Book of the National Physical Laboratory. Londres: Oficina de papelería
de Su Majestad, 1951.
Lebow, Irwin.Autopistas y caminos de la información: del telégrafo al siglo XXI.Nueva York:

IEEE Press, 1995.
Licklider, JCR "Computadoras y gobierno". En La era de la informática: una visión de veinte años , editado
por Michael L. Dertouzos y Joel Moses. Serie Bicentenario del MIT.
Cambridge: MIT Press, 1979.
———Bibliotecas del futuro. Cambridge: MIT Press, 1965.
Padlipsky, M. A. Los elementos del estilo de las redes y otros ensayos y versiones animadas del arte de las
redes entre computadoras. Englewood Cliffs, Nueva Jersey: PrenticeHall, Inc., 1985.
Actas del Quinto Simposio sobre Comunicaciones de Datos. IEEE Computer Society, Snowbird, Utah,
27 al 29 de septiembre de 1977.
Pyatt, Edward. El Laboratorio Nacional de Física: una historia. Bristol, Inglaterra: Adam Hilger Ltd., 1983.
Redmond, Kent C. y Thomas M. Smith. El proyecto Whirlwind: la historia de una computadora pionera.
Bedford, Mass.: Digital Press, 1980.
Rheingold, Howard. La comunidad virtual. Nueva York: Harper Perennial, 1994.

———Herramientas para el pensamiento: las personas y las ideas detrás de la próxima revolución
informática. Nueva York: Simon & Schuster, 1988.
Roberts, Lawrence G. "ARPANET y las redes informáticas". En Una historia de las estaciones de trabajo
personales, editado por Adele Goldberg. Reading, Massachusetts: ACM Press (AddisonWesley), 1988.
Rose, Marshall T.El mensaje de Internet: cerrar el libro con el correo electrónico.Englewood
Cliffs, Nueva Jersey: PTR Prentice Hall, 1993.
Sherman, Kenneth. Comunicaciones de datos: una guía del usuario . Reston, Virginia: Reston Publishing
Company, 1981.
Smith, Douglas K. y Robert C. Alexander. Buscando el futuro: cómo Xerox inventó y luego ignoró la primera
computadora personal. Nueva York: William Morrow, 1988.
Udall, Stewart L. Los mitos de agosto: una exploración personal de nuestro trágico asunto de la Guerra Fría
con el átomo. Nueva York: Pantheon, 1994.
Wildes, Karl L. y Nilo A. Lindgren. Un siglo de ingeniería eléctrica e informática en el MIT, 1882–1982. Cambridge,
Mass.: MIT Press, 1985.
Ganador, Langdon. La ballena y el reactor: una búsqueda de límites en una era de alta tecnología. Chicago:
University of Chicago Press, 1986.
Diario, revista y periódico

Artículos
Abramson, normando. “Desarrollo de Alohanet”. IEEE Transactions on Information Theory, enero de 1985.
Anderson, Cristóbal. “The Accidental Superhighway”. The Economist, 1 de julio de 1995.
Barán, Pablo. “Sobre redes de comunicaciones distribuidas”. IEEE Transactions on Communications

Systems, 1 de marzo de 1964.
———“Sistemas de comunicaciones digitales confiables que utilizan nodos repetidores de red no confiables”.
Informe de la División de Matemáticas de RAND Corporation No. P1995, 27 de mayo de 1960.
Boggs, David R., John F. Shoch, Edward A. Taft y Robert M. Metcalfe. "PUP: una arquitectura de red de
Internet". IEEE Transactions on Communications, abril de 1980.
"Bolt Beranek acusado por el gobierno de sobrecargos contractuales". Historias combinadas de Dow Jones
News Service – Wall Street Journal, 27 de octubre de 1980.
"Bolt Beranek y Newman: dos ayudantes se declaran culpables de los cargos estadounidenses". Historias
combinadas de Dow Jones News Service – Wall Street Journal, 12 de noviembre de 1980.
“Bolt Beranek, ayudantes acusados de engañar a Estados Unidos en varios trabajos”. The WallStreet
Journal, 28 de octubre de 1980.
Bulkeley, William M. "¿Puede convertir grandes ideas en grandes ventas?" The WallStreet Journal,
12 de septiembre de 1994.
Bush, Vannevar. “Como podemos pensar”. Atlantic Monthly, julio de 1945.
CampbellKelly, Martín. “Comunicaciones de datos en el Laboratorio Nacional de Física: 19651975”.

Anales de Historia de la Computación9, no. 3/4, 1988.
Cerf, Vinton G. y Peter T. Kirstein. "Problemas en la interconexión de redes de

paquetes". Actas del IEEE, noviembre de 1979.
Cerf, Vinton G. y Robert E. Kahn. “Un protocolo para la intercomunicación de redes de

paquetes”. IEEE Transactions on Communications, mayo de 1974.
Cerf, Vinton. “PARRY se encuentra con el médico: conversación entre un paranoico simulado y un
psiquiatra simulado”. Datamation, julio de 1973.
Clark, David D. “The Design Philosophy of the DARPA Internet Protocols”. Actas del Simposio sobre
comunicaciones de datos de la Association for Computing Machinery Sigcomm, agosto de
1988.
Clark, David D., Kenneth T. Pogran y David P. Reed. “Introducción a las redes de área local”. Actas del IEEE,
noviembre de 1979.
Comer, Douglas. “La Red de Investigación en Ciencias de la Computación CSNET: Informe de historia y
estado ”. Comunicaciones de la ACM, octubre de 1983.
Crowther, WR, FE Heart, AA McKenzie, JM McQuillan y DC

Walden. “Problemas en el diseño de redes de conmutación de paquetes”. Actas de la Conferencia
Nacional de Computación de 1975, 1975.
Denning, Peter J. "La ciencia de la informática: TheARPANETAfter Twenty Years". Científico

estadounidense, noviembrediciembre de 1989.
Denning, Peter J., Anthony Hearn y C. William Kern. “Historia y descripción general de CSNET. “Actas
del Simposio sobre comunicaciones de datos de Sigcomm de la Asociación de Maquinaria de Computación,
marzo de 1983.
"Dr. JCR Licklider recibe el premio bienal en la reunión de State College”. The Journal of the Acoustical
Society of America, noviembre de 1950.
Engelbart, Douglas C. "Servicios de información coordinados para una comunidad orientada a la disciplina
o la misión ". Actas de la Segunda Conferencia Anual de Comunicaciones por Computadora, enero de
1972.
——— “Implicaciones intelectuales de las redes informáticas de acceso múltiple ”. Actas de la conferencia
interdisciplinaria sobre redes informáticas de acceso múltiple, Austin, Texas, abril de 1970.
Ericson, Raymond. "La acústica del Philharmonic Hall hace que los rumores comiencen a volar". The NewYork
Times, 4 de diciembre de 1962.
Finucane, Martín. “Los creadores del precursor de Internet se reúnen en Boston”. Reading (Massachusetts)
Heraldo del Daily Times, 12 de septiembre de 1994.
Pescador, Sharon. “La red informática más grande: Internet conecta computadoras UNIX en todo el
mundo”. InfoWorld, 25 de abril de 1988.
Hines, William. “Correo”. Chicago SunTimes, 29 de marzo de 1978.
Haughney, Joseph F. "Anatomía de una revisión de la conmutación

de paquetes". DataCommunications, junio de 1982.
Holusha, Juan. "Computer Tied Carter, Mondale Campaigns: The Bethesda Connection".
Washington Star, 21 de noviembre de 1976.
Jacobs, Irwin M., Richard Binder y EstilV. Hoversten. “ Redes de satélites de paquetes de uso general”.
Actas del IEEE, noviembre de 1978.
Jennings, Dennis M., Lawrence H. Landweber, Ira H. Fuchs, David J. Farber y W.

Richards Adrión. “Redes informáticas para científicos”. Science, 22 de febrero de 1986.
Kahn, Robert E. "El papel del gobierno en la evolución de Internet". Comunicaciones

de la ACM, agosto de 1994.
Kahn, Robert E., Steven A. Gronemeyer, Jerry Burchfiel y Ronald C. Kunzelman.

“Advances in Packet Radio Technology”. Actas del IEEE, noviembre de 1978.
Kantrowitz, Barbara y Adam Rogers. “El nacimiento de Internet”. Newsweek, 8 de agosto de 1994.
Kleinrock, Leonard. “Principios y lecciones en comunicaciones por paquetes”. Actas del IEEE, noviembre de 1978.
Landweber, Lawrence H., Dennis M. Jennings e Ira Fuchs. "Investigación de redes informáticas y su
interconexión". Revista IEEE Communications, junio de 1986.
Lee, JAN y Robert F. Rosin. “The CTSS Interviews”. IEEE Annals of the History of Computing14, no. 1, 1992.
———“Las entrevistas del Proyecto MAC”. IEEE Annals of the History of Computing14, no. 2, 1992.
Licklider, JCR "A Gridless, Wireless RatShocker". Revista de Psicología Comparada y Fisiológica 44,
1951.
——— "Simbiosis hombrecomputadora". Reimpresión. In Memoriam: JCR Licklider. Centro de investigación

de sistemas de Digital Equipment Corporation, 7 de agosto de 1990.
Licklider, JCR y Albert Vezza. “Aplicaciones de redes de información”. Actas del

IEEE, noviembre de 1978.
Licklider, JCR y Robert W. Taylor. "La computadora como dispositivo de comunicación".

Reimpresión. In Memoriam: JCR Licklider. Centro de investigación de sistemas de Digital Equipment
Corporation, 7 de agosto de 1990.
Markoff, John. “Arriba del subsuelo informático”. The NewYork Times, 27 de agosto de 1993.
McKenzie, Alexander A. y BP Cosell, JM McQuillan, MJ Thrope. “El Centro de control de red para la
red ARPA”. Actas del IEEE, 1972.
Mier, Edwin E. "Departamento de Defensa preparando murallas de

red". DataCommunications, octubre de 1983.
Molinos, Jeffrey. "Correo electrónico." Associated Press, 4 de enero de 1976.
."Correo electrónico." Associated Press, 19 de junio de 1976.
——— "El servicio postal prueba el servicio de mensajes electrónicos". Associated Press, 28 de marzo de
1978.
Mills, Kay. "La preocupación pública: el correo". Servicio de noticias Newhouse, 27 de julio de 1976.
Mohl, Bruce A. “2 Bolt, Beranek Officials Collapse in Federal Court”. TheBoston Globe, 31 de octubre
de 1980.
Pallesen, Gayle. “Empresa consultora en PBIA enfrenta cargos penales”. PalmBeach (Florida) Post,
8 de noviembre de 1980.
Pearse, Ben. “Jefe de defensa en la era del Sputnik”. The NewYork Times Magazine, 10 de noviembre
de 1957.
Piscina, Bob. "Inventar el futuro: el científico de UCLA que ayudó a crear Internet aún no ha terminado".
Los Angeles Times, 11 de agosto de 1994.
Quarterman, John S. y Josiah C. Hoskins. “ Redes informáticas notables”.

Comunicaciones de la ACM, octubre de 1986.
Roberts, Lawrence G. “ARPA Network Implications”. Educacom, Boletín del Consejo

Interuniversitario de Comunicaciones, otoño de 1971.
Salus, Pedro. “Pioneros de Internet”. Internet World, septiembre de 1994.

“Scanning the Issues”, IEEE Spectrum, agosto de 1964.
Schonberg, Harold C. “Cuatro expertos en acústica instan a realizar revisiones en el auditorio”. The NewYork
Times, 4 de abril de 1963.
———“Acústica otra vez: la Filarmónica tiene algunos defectos, pero también tiene una poesía propia”. The NewYork
Times, 9 de diciembre de 1962.
Venderlo . Consumer Reports, junio de 1977.
Agencias espaciales. “ARPA da forma a la investigación espacial militar”. Semana de la aviación, 16 de junio de 1958.
Sterling, Bruce. “Internet”. Fantasía y ciencia ficción, febrero de 1993.
Swartzlander, conde. “Tiempo compartido en el MIT”. IEEE Annals of the History of Computing14, no. 1, 1992.
"Transformando BB&N: el arquitecto de ARPANET apunta a redes no militares". Comunicaciones de datos, abril
de 1984.
Wilson, David McKay. “Los ejecutivos de BBN colapsan en los tribunales”. Cambridge (Massachusetts)
Crónica, 6 de noviembre de 1980.
——— “Consulting Co. Admits Overcharge”. Cambridge (Massachusetts) Chronicle, 30 de octubre de 1980.
Zitner, Aarón. “Un silencioso salto adelante en el ciberespacio”. The Boston Globe, 11 de septiembre de 1994.
Zuckerman, Laurence. “BBN sale de las sombras y se convierte en el centro de atención”. The NewYork Times,
17 de julio de 1995.
Artículos inéditos, entrevistas de

Fuentes secundarias y otras
Documentos
"Acto uno." Simposio sobre la historia de ARPANET celebrado en la Universidad de California en Los
Ángeles, el 17 de agosto de 1989. Transcripción.
Centro de información de la red ARPA, Instituto de Investigación de Stanford, Menlo Park, California.
Folleto “Escenarios de uso de ARPANET”. Preparado para la Conferencia Internacional sobre Comunicaciones
Informáticas, Washington, DC, octubre de 1972.
Barán, Pablo. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral
DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad
de Minnesota, Minneapolis, Minn., 5 de marzo de 1990.
Barlow, John Perry. "Crimen y perplejidad". Pinedale, Wyoming, junio de 1990.
Corporación BBN Sistemas y Tecnologías. “Informe Anual del Programa de

Desarrollo Científico”. Cambridge, Massachusetts, 1988.
Bhushan, AK "Comentarios sobre el protocolo de transferencia de archivos". Solicitud de comentarios 385.

Instituto de Investigación de Stanford, Menlo Park, California, agosto de 1972.
———“El Protocolo de Transferencia de Archivos”. Solicitud de comentarios 354. Stanford Research

Institute, Menlo Park, California, julio de 1972.
Bhushan, Abhay, Ken Pogran, Ray Tomlinson y Jim White. "Estandarización de los encabezados
de correo de red". Solicitud de comentarios 561. MIT, Cambridge, Mass., 5 de septiembre de 1973.
Azul, Alan. Entrevista de William Aspray. Instituto Charles Babbage, Colección de Historia Oral
DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de
Minnesota, Minneapolis, Minn., 12 de junio de 1989.
Bolt Beranek y Newman Inc. "Informe de finalización de ARPANET: borrador". Cambridge,

Massachusetts, septiembre de 1977.
———“Propuesta BBN No. IMP P69IST5: Procesadores de mensajes de interfaz para la red
informática ARPA”. Propuesta de diseño. Presentado al Departamento del Ejército,
Servicio de Suministros de Defensa, en respuesta a la RFQ No. DAHC15 69 Q 0002. Washington,
DC, 6 de septiembre de 1968.
——— “Informe BBN No. 1763: Diseño inicial de procesadores de mensajes de interfaz para el
Red informática ARPA”. Propuesta de diseño. Presentado a la Agencia de Proyectos de
Investigación Avanzada bajo el contrato no. DAHC 1569C0179. Washington, DC, 6 de enero
de 1969.
——— "Informe BBN n.º 1822: Procesador de mensajes de interfaz". Reporte técnico.
Cambridge, Massachusetts, 1969.
———“Procesadores de mensajes de interfaz para la red informática ARPA”. Informes

técnicos trimestrales. Presentado a la Agencia de Proyectos de Investigación Avanzada
bajo el contrato no. DAHC 1569C0179 y contrato no. F0860673C0027. Washington, DC, 1969–
1973.
——— "Manual de funcionamiento para procesadores de mensajes de interfaz: 516 IMP, 316 IMP, TEP".
Revisado. Presentado a la Agencia de Proyectos de Investigación Avanzada bajo la orden ARPA
no. 1260, contrato no. DAHC1569C0179. Arlington, Virginia, abril de 1973.
——— "Informe No. 4799: Una historia de ARPANET: la primera década". Presentado a la Agencia
de Proyectos de Investigación Avanzada de Defensa. Arlington, Virginia, abril de 1981.
———“El Plan de las Cuatro Ciudades”. Borrador de propuesta y análisis de costos para mantenimiento
de IMP y TIP en Boston, Washington, Los Ángeles y San Francisco. Artículos de BBN División
6. Cambridge, Mass., abril de 1974.
——— Memorandos internos y documentos relacionados con el trabajo de la División 6. Cambridge,

Mass., 1971–1972.
Carr, C. Stephen, Stephen D. Crocker y Vinton G. Cerf. "Protocolo de comunicación

HOSTHOST en la red ARPA". Documento presentado en la Conferencia Conjunta de Computación
de Primavera de la Federación Estadounidense de Sociedades de Procesamiento de Información,
1970.
Catton, General de División, USAF, Jack. Carta a FR Collbohm de RAND Corporation, 11 de octubre
de 1965. Remitiendo el plan de desarrollo técnico preliminar para la red de bloqueo de mensajes a la
Agencia de Comunicaciones de Defensa.
Cerf, Vinton G. "Confesiones de un ingeniero con discapacidad auditiva". Inédito.
———“PARRY se encuentra con el Doctor”. Solicitud de comentarios 439 (NIC 13771).

Grupo de trabajo de la red, 21 de enero de 1973.
Cerf, Vinton G. y Jonathan B. Postel. "Especificación del protocolo de control de transmisión de

redes: TCP versión 3". Instituto de Ciencias de la Información, Universidad del Sur de California, enero
de 1978.
Cerf, Vinton G. Entrevista realizada por Judy O'Neill. Instituto Charles Babbage, Colección de
Historia Oral DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la
Universidad de Minnesota, Minneapolis, Minn., 24 de abril de 1990.
Cerf, Vinton G. y Robert Kahn. "Protocolos a nivel de HOST y PROCESO para la

comunicación entre redes". Notas del Grupo de Trabajo de la Red Internacional 39, 13 de septiembre
de 1973.
Clark, Wesley. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral DARPA/
IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de
Minnesota, Minneapolis, Minn., 3 de mayo de 1990.
Crocker, David H. "Estándar para el formato de mensajes de texto de Internet ARPA". Solicitud de
comentarios 822. Departamento de Ingeniería Eléctrica, Universidad de Delaware, 13 de agosto de
1982.
Crocker, David H., John J. Vittal, Kenneth T. Pogran y D. Austin Henderson Jr.
"Estándar para el formato de mensajes de texto de la red ARPA". Solicitud de comentarios 733.
The RAND Corporation, Santa Mónica, California, 21 de noviembre de 1977.
Crowther, William. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral
DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de
Minnesota, Minneapolis, Minn., 12 de marzo de 1990.
Crowther, William y David Walden. "Vistas actuales del tiempo". Memorando a Frank E. Heart,
Cambridge, Mass., 8 de julio de 1969.
Davies, Donald W. "Más especulaciones sobre la transmisión de datos". Papeles privados. Londres, 16 de
noviembre de 1965.
———“Propuesta de Red de Comunicación Digital”. Documentos privados, fotocopiados y de amplia

circulación. Londres, junio de 1966.
——— “Propuesta para el Desarrollo de un Servicio Nacional de Comunicaciones para el Procesamiento

de Datos en Línea”. Papeles privados. Londres, 15 de diciembre de 1965.
——— "Procesamiento remoto de datos en línea y sus necesidades de comunicación". Papeles

privados. Londres, 10 de noviembre de 1965.
Davies, Donald W. Entrevista realizada por Martin CampbellKelly. Laboratorio Nacional de Física, Reino
Unido, 17 de marzo de 1986.
Davies, Donald W., Keith Bartlett, Roger Scantlebury y Peter Wilkinson. "Una red de comunicaciones
digitales para computadoras que brinda una respuesta rápida en terminales remotas".
Documento presentado en el Simposio de la Association for Computing Machinery sobre principios de
sistemas operativos, Gatlinburg, Tennessee, octubre de 1967.
Davis, Ruth M. "Comentarios y recomendaciones sobre la red ARPA".

Centro de Ciencias y Tecnología de la Computación, Oficina Nacional de Estándares de EE. UU., 6 de
octubre de 1971.
Corporación de equipos digitales. "Procesadores de mensajes de interfaz para la red informática ARPA".
Propuesta de diseño. Presentado al Departamento del Ejército, Servicio de Suministros de Defensa, en
RFQ no. DAHC15 69 Q 002, 5 de septiembre de 1968.
Frank, Howard. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral DARPA/
IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota,
Minneapolis, Minn., 30 de marzo de 1990.
Goldstein, Pablo. "La propuesta de desinversión de ARPANET: cuestiones legales y cuestiones

económicas". Documento de trabajo, Cabledata Associates, Inc., CAWP no. 101, 27 de julio de 1973.
Hauben, Michael y Ronda Hauben. La página Netizens Netbook se puede encontrar en http://
www.columbia.edu/~hauben/netbook/. El trabajo de los Haubens también apareció en el Amateur
Computerist Newsletter, disponible en ftp://wuarchive.wustl.edu/
doc/misc/acn/.
Heart, FE, RE Kahn, SM Ornstein, WR Crowther y DC Walden. "El procesador de mensajes de

interfaz para la red informática ARPA". Documento presentado en la Conferencia Conjunta de Computación
de Primavera de la Federación Estadounidense de Sociedades de Procesamiento de Información, 1970.
Corazón, Frank E. Entrevista realizada por Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral
DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota,
Herzfeld, Carlos. Entrevista realizada por Arthur Norberg. Instituto Charles Babbage, Colección de
Historia Oral DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota,
Minneapolis, Minn., 6 de agosto de 1990.
Honeywell, Inc. “Honeywell en Bolt Beranek y Newman, Inc.” Folleto. Publicado para la demostración de la red ARPA en
la Conferencia Internacional sobre Comunicaciones por Computadora, Washington, DC, octubre de 1972.
Instituto de Ciencias de la Información, Universidad del Sur de California. "Protocolo de control de transmisión
estándar del DOD". Solicitud de comentarios 761. Preparado para la Agencia de Proyectos de Investigación Avanzada
de Defensa, Oficina de Técnicas de Procesamiento de Información, Arlington, Va., enero de 1980.
Corporación Internacional de Datos. "ARPA Computer Network proporciona tecnología de comunicaciones para la
interacción computadora/computadora dentro de una comunidad de investigación especial".
Informe de la industria y revisión del mercado. Newtonville, Massachusetts, 3 de marzo de 1972.
Kahn, Robert. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral DARPA/IPTO, Centro
para la Historia del Procesamiento de la Información de la Universidad de Minnesota, Minneapolis, Minn., 24 de
abril de 1990.
Kahn, Robert. Entrevista de William Aspray. Instituto Charles Babbage, Colección de Historia Oral DARPA/IPTO,
Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota, Minneapolis, Minn., 22
de marzo de 1989.
Kleinrock, Leonard. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral
DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota, Minneapolis,
Minn., 3 de abril de 1990.
Kryter, Karl D. "Lick como psicoacústico y fisioacústico". Presentación en honor a JCR Licklider en la reunión de
la Acoustical Society of America, Baltimore, Maryland, 30 de abril de 1991.
——— Obituario de JCR Licklider, Revista de la Sociedad Acústica de América, diciembre de

1990.
Licklider, JCR y Welden E. Clark. "Comunicación hombrecomputadora en línea".

Documento presentado en la Conferencia Conjunta de Computación de Primavera de la Federación Estadounidense de
Sociedades de Procesamiento de Información, 1962.
Licklider, JCR Entrevista realizada por William Aspray. Instituto Charles Babbage, Colección de Historia
Oral DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota,
Minneapolis, Minn., 28 de octubre de 1988.
Lukasik, Stephen. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral DARPA/
Minneapolis, Minn., 17 de octubre de 1991.
Marill, Thomas y Lawrence G. Roberts. "Hacia una red cooperativa de computadoras en tiempo
compartido". Documento presentado en la Conferencia Conjunta de Computación de Otoño de la
Federación Estadounidense de Sociedades de Procesamiento de Información, 1966.
McCarthy, J., S. Boilen, E. Fredkin y JCR Licklider. "Un sistema de depuración de tiempo compartido para una
computadora pequeña". Documento presentado en la Conferencia Conjunta de Computación de Primavera de
la Federación Estadounidense de Sociedades de Procesamiento de Información, 1963.
McKenzie, Alexander A. "El Centro de control de red ARPA". Trabajo presentado en el Cuarto Simposio
sobre Comunicaciones de Datos del Instituto de Ingenieros Eléctricos y Electrónicos, octubre de 1975.
McKenzie, Alexander A. Entrevista realizada por Judy O'Neill. Instituto Charles Babbage, Colección
de Historia Oral DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de
Minnesota, Minneapolis, Minn., 13 de marzo de 1990.
Grupo de mensajes. El texto completo de más de 2.600 mensajes de correo electrónico enviados por
miembros del Message Group (o MsgGroup), una de las primeras listas de correo electrónico, relacionada con
el desarrollo del correo electrónico. The Computer Museum, Boston, Mass., junio de 1975 a junio de 1986.
Documento electrónico. (http://www.tcm.org/msgroup)
Metcalfe, Robert. "Algunos momentos históricos en el networking". Solicitud de comentarios 89.

Grupo de trabajo de la red, 19 de enero de 1971.
Myer, TH y DA Henderson. "Protocolo de transmisión de mensajes". Solicitud de comentarios 680.

Stanford Research Institute, Menlo Park, California, 1975.
Consejo Nacional de Investigaciones, Comisión de Ingeniería y Sistemas Técnicos.

"Protocolos de transporte para redes de datos del Departamento de Defensa". Informe al
Departamento de Defensa y a la Oficina Nacional de Normas, Junta de Telecomunicaciones
y Aplicaciones Informáticas, 1985.
Neigus, Nueva Jersey "Protocolo de transferencia de archivos". Solicitud de comentarios 542. Bolt Beranek
and Newman Inc., Cambridge, Mass., 12 de julio de 1973.
Norberg, Arthur L. y Judy E. O'Neill. "Una historia de la Oficina de Técnicas de Procesamiento de

Información de la Agencia de Proyectos de Investigación Avanzada de Defensa". Instituto Charles
Babbage, Universidad de Minnesota, Minneapolis, Minnesota, 1992.
Ornstein, Severo M., FE Heart, WR Crowther, HK Rising, SB Russell y A.

Míchel. "La Terminal IMP para la Red ARPA". Documento presentado en la Conferencia Conjunta de
Computación de Primavera de la Federación Estadounidense de Sociedades de Procesamiento de
Información, Atlantic City, Nueva Jersey, mayo de 1972.
Ornstein, Severus. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral DARPA/
Pogran, Ken, John Vittal, Dave Crowther y Austin Henderson. "Norma oficial propuesta para el formato
de mensajes de la red ARPA". Solicitud de comentarios 724. MIT, Cambridge, Mass., 12 de mayo de 1977.
Postel, Jonathan B. "Protocolo simple de transferencia de correo". Solicitud de comentarios 821.

Instituto de Ciencias de la Información, Universidad del Sur de California, agosto de 1982.
——— "Especificación del protocolo de control de transmisión de redes: TCP versión 4".
Instituto de Ciencias de la Información, Universidad del Sur de California, septiembre de 1978.
——— "Desactivación de TCP e IP". Solicitud de comentarios 1025. Grupo de trabajo de la red, septiembre
de 1987.
Pouzin, Luis. "Protocolos de red". Notas del Grupo de Trabajo de la Red Internacional 50, septiembre de 1973.
———“Presentación y principales aspectos de diseño de la red informática de las Cícladas”.

Trabajo presentado en el Tercer Simposio de Comunicaciones de Datos del IEEE (Redes de Datos:
Análisis y Diseño), noviembre de 1973.
——— "Protocolo de comunicación experimental: marco de mensaje básico". Notas del Grupo de Trabajo
de la Red Internacional 48, enero de 1974.
———“Interconexión de Redes de Conmutación de Paquetes”. Notas del Grupo de Trabajo de la Red

Internacional 42, octubre de 1973.
——— "Arquitectura y componentes de red". Notas del Grupo de Trabajo de la Red Internacional 49,
agosto de 1973.
Corporación RAND. "Desarrollo de la red distribuida de bloques de mensajes adaptativos".

Recomendación al Estado Mayor del Aire, 30 de agosto de 1965.
RCA Service Company, División de Servicios Gubernamentales. "Informe final del estudio
ARPANET". Presentado bajo contrato no. F0860673C0018. 24 de noviembre de 1972.
Richard J. Barber Associates, Inc. “La Agencia de Proyectos de Investigación Avanzada: 1958–
1974”. Un estudio para la Agencia de Proyectos de Investigación Avanzada bajo el contrato no.
MDA90374C0096. Washington, DC, diciembre de 1975. Fotocopia.
Roberts, Lawrence G. "Extensiones de la tecnología de comunicaciones por paquetes a una terminal

personal portátil". Documento presentado en la Conferencia Conjunta de Computación de Primavera de la
Federación Estadounidense de Sociedades de Procesamiento de Información, mayo de 1972.
——— "Múltiples redes informáticas y comunicación entre computadoras". Documento presentado en el

Simposio de la Asociación de Maquinaria de Computación sobre Principios de Sistemas Operativos, octubre de 1967.
Roberts, Lawrence G. y Barry D. Wessler. "Desarrollo de redes informáticas para lograr el intercambio de
recursos". Documento presentado en la Conferencia Conjunta de Computación de Primavera de la Federación
Estadounidense de Sociedades de Procesamiento de Información, 1970.
Roberts, Lawrence G. Entrevista realizada por Arthur Norberg. Instituto Charles Babbage, Colección de
Historia Oral DARPA/IPTO, Centro para la Historia del Procesamiento de la Información de la Universidad de Minnesota,
Minneapolis, Minn., 4 de abril de 1989.
Ruina, Jack. Entrevista de William Aspray. Instituto Charles Babbage, Colección de Historia Oral DARPA/IPTO,
de abril de 1989.
Sutherland, Iván. Entrevista de William Aspray. Colección de Historia Oral del Instituto Charles Babbage DARPA/IPTO,
de mayo de 1989.
Taylor, Roberto. Entrevista de William Aspray. Instituto Charles Babbage, Colección de Historia Oral DARPA/IPTO,
de febrero de 1989.
Servicio Postal de EE. UU. "Sistemas de mensajes electrónicos para el servicio postal de EE. UU.". Informe del Panel
de Apoyo del USPS, Comité de Telecomunicaciones, Washington, DC, enero de 1977.
Walden, David C. "Experiencias en la construcción, operación y uso de la red ARPA".

Trabajo presentado en la Segunda Conferencia de Informática entre Estados Unidos y Japón, Tokio, Japón, agosto
de 1975.
Walden, David. Entrevista de Judy O'Neill. Instituto Charles Babbage, Colección de Historia Oral DARPA/IPTO,
de febrero de 1990.
Walker, Stephen T. "Informe final: Desarrollo de la red ARPA". Agencia de Proyectos de Investigación
Avanzada de Defensa, Oficina de Técnicas de Procesamiento de Información, Washington, DC, 4 de enero
de 1978.
Weik, Martin H. "Un tercer estudio sobre los sistemas informáticos digitales electrónicos domésticos".
Laboratorios de investigación balística, informe no. 1115, marzo de 1961.
Blanco, Jim. "Protocolo de correo propuesto". Solicitud de comentarios 524. Stanford Research Institute, Menlo
Park, California, 13 de junio de 1973.
Zimmermann, H. y M. Elie. "Protocolo estándar hosthost propuesto para redes informáticas

heterogéneas: protocolo de transporte". Notas del Grupo de Trabajo de la Red Internacional 43, diciembre de
1973.
Archivos electrónicos
Instituto Charles Babbage, Centro de Historia del Procesamiento de la Información, Universidad de
Minnesota. Gran colección de archivos relacionados con la historia de la informática. Se
puede obtener más información a través del sitio web de
CBI en http://cbi.itdean.umn.edu/cbi/welcome.html o por correo electrónico
dirigido a bruce@fs1.itdean.umn.edu.
Museo de la Computación, Boston, Massachusetts. Gran colección relacionada con la historia de

la informática, incluidos los archivos del Message Group sobre el desarrollo inicial del
correo electrónico. El archivo está disponible a través de la página de inicio
en http://www.tcm.org/msgroup.
Instituto de Ciencias de la Información, Universidad del Sur de California. La colección incluye índices
y pruebas actualizados de estándares, protocolos, solicitudes de comentarios (RFC) de Internet y
varias otras notas técnicas disponibles a través del sitio web de ISI: http://www.isi.edu. Algunos de los
RFC anteriores no están disponibles electrónicamente, pero el editor de RFC, Jon Postel,
los archiva fuera de línea de manera meticulosa. Se mantiene un archivo con capacidad de
búsqueda en http://info.internet.isi.edu:80/innotes/rfc.
Universidad Estatal de Ohio, Departamento de Informática y Ciencias de la Información. El servidor

web CIS ofrece acceso a RFC y otros documentos técnicos e históricos relacionados con Internet a
través de http://www.cis. ohiostate.edu:80/hypertext/information/rfc.html.
Expresiones de gratitud
Este libro surgió de una idea que se originó con los ingenieros de Bolt Beranek y Newman.
Los recuerdos se estaban volviendo borrosos a finales de 1993, cuando empezamos a pensar
en escribir un libro, y Frank Heart y otros estaban interesados en que se registrara el
considerable papel de BBN en la creación del ARPANET original. La empresa no sólo nos abrió
sus archivos y cooperó en todos los sentidos, sino que también ayudó a financiar el proyecto, aunque
acordó no ejercer ningún control sobre el contenido del libro. Marian Bremer, entonces
bibliotecaria principal de BBN, hizo la llamada telefónica inicial que condujo al libro. Cary Lu y John
Markoff nos instaron a asumir el proyecto.
Helen Samuels y la gente de los archivos del MIT fueron de gran ayuda, al igual que Kevin
Corbitt, archivero asistente del Instituto Charles Babbage, Centro para la Historia del
Procesamiento de la Información de la Universidad de Minnesota. Agradecemos a John Day,
Larry Roberts, Al Vezza y John Shoch por buscarnos en cajas viejas.
Deborah Melone y Bob Menk enviaron fotografías y archivos de BBN. Kevin Kelly y Martha Baer de
la revista Wired nos centraron en la historia del correo electrónico. Noel Chiappa, bondadoso tutor,
pasó horas al teléfono explicando, entre otros puntos técnicos, cómo funcionan las tablas de
enrutamiento y los RFNM.
Las siguientes personas nos permitieron entrevistarlos detalladamente: Wes Clark, Vint Cerf, Bob Kahn,
Severo Ornstein, Bob Taylor, Larry Roberts, Jon Postel, Frank Heart, Alex McKenzie, Dave
Walden, Ben Barker, Donald Davies, Paul Baran, Len Kleinrock, Steve Lukasik, Steve Crocker y Bob
Metcalfe. Louise Licklider, Bill McGill, John Swets y Karl Kryter compartieron sus recuerdos de JCR
Licklider con nosotros, y Mitch Waldrop ayudó a llenar algunos espacios en blanco. Phil Patton nos
confió su copia del estudio de Barber Associates, por lo que le estamos agradecidos. Brian Reid, Gary
Chapman, Kevin Buckley, Dave Farber y el coronel Clair Shirey nos permiten analizar varios
temas relevantes.
Marsha Longshore del IEEE nos envió artículos técnicos y Earl Swartzlander nos prestó sus copias de
los anales de la historia de la informática del IEEE. Steve Wolff nos ayudó a comprender los
acontecimientos, a menudo laberínticos, que tuvieron lugar en la década de 1980, en particular en
relación con el papel de NSF en el desarrollo de Internet.
El manuscrito fue leído total o parcialmente en varias etapas de finalización por Vint Cerf, Lyman Chapin,
Steve Crocker, Peter Denning, Frank Heart, Bob Kahn, John Kelley, Larry Landweber, Steven Levy,
Hank Long, Paul McJones, Alex McKenzie. , Peter Preuss, Larry Roberts, Einar Stefferud, Bob Taylor,
John Vittal, Dave Walden y Susan Zacharias. Everett Hafner, perfeccionista y caballo de batalla,
nos mantuvo honestos. El manuscrito se benefició enormemente de la mente aguda y la pluma
cuidadosa de Richard Lyon.
La responsabilidad de los errores, por supuesto, recae en nosotros.
Jon Coifman, nuestro excelente asistente de investigación, ayudó enormemente en las etapas finales
de la preparación del manuscrito, y Andrea Perry fue una cuidadosa correctora. Julian Darley
ayudó a escribir los cambios. Denise Bugg transcribió muchas cintas. Pete Lewis salvó el día con su
Pen Tablet Wacom. Sigrid Cerf nos brindó coloridas historias y muchos sabios consejos. Matt Pallakoff,
quien escribió Retrieve It!, ayudó a reducir horas de nuestras semanas laborales.
Y gracias a John Aielli, quién sabe por qué.
Zoë Mark Lyon, aunque ocupada con su propio libro, se tomaba un tiempo de su agenda todos los
días para animarnos y hacernos reír. Denny Lyon, Amy Goodwin, Kelly McRee, Ellen Lyon y Jeremy
Lyon asumieron valientemente el cuidado infantil adicional. Sherry Turkle, Sarah Hafner, Teresa
Carpenter, Terry Evers, Robert Wallich, Tony Bianco y Carol Flake prestaron oídos comprensivos.
Ladd Hanson y Mark McFarland ayudaron con los problemas técnicos. George Hackett y Bob Berdahl
fueron jefes que sufrieron mucho tiempo, en contra de su mejor criterio. Ann Walther, Lindsey Lane
y Tom Ferguson (encargado del contador postal) acudieron al rescate más de una vez. Paulina Borsook
ofreció sus invaluables ideas habituales.
Durante nuestros viajes, Chris Paine, Katherine Magraw, Holly Myers, Kirk Neely, Lisa Van Dusen,
Candace Thille, Julie Graham, Debbie Yager, Katherine e Irving Gottsegen, Jane y Frank Heart, Barry
Muhlfelder, Jane Anderson y Eric Ponteri pusieron un techo sobre nuestras cabezas.
Como de costumbre, los agentes literarios John Brockman y Katinka Matson sabían que allí había
un libro. Bob Bender, nuestro maravilloso editor de Simon & Schuster, sabía cuál debería ser ese
libro. Su maravillosa asistente, Johanna Li, nunca nos defraudó.
—Katie Hafner
katieh@zilker.net
—Matthew Lyon
m_lyon@utxvms.cc.utexas.edu

Spanish S3T1Where Wizards Stay Up Late The Origins of The Internet

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Spanish S3T1Where Wizards Stay Up Late The Origins of The Internet

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

DONDE SE ALOJAN LOS MAGOS

(LOS ORÍGENES DE INTERNET)

Katie Hafner y Mateo

Un lanzamiento de NERD de DF Books

Visítenos en la World Wide Web: http://

Copyright © 1996 de Katie Hafner y Matthew Lyon

Primera edición de Touchstone 1998

TOUCHSTONE y colofón son marcas registradas de Simon & Schuster Inc.

A la memoria de JCR Licklider

También por Katie Hafner

La casa del puente: una historia de la Alemania moderna

Cyberpunk: forajidos y piratas informáticos en la frontera informática (con John Markoff)

Katie Hafner y Matthew Lyon

UN LIBRO DE PIEDRA DE TOQUE

Publicado por Simon & Schuster

1.El millón de dólares más rápido

2.Un bloque aquí, algunas piedras allá

3.La Tercera Universidad

4. Dirígete hacia abajo en los bits

5.Hazlo con Truett

8.Un cohete en nuestras manos

Notas del capítulo

(Quédate en el auto, olvídate de la puerta)

Para salvar el mundo o acabar con él, el tiempo lo dirá

"Bajo Libra: pesos y medidas",

fromDesafiando los elementos

La presencia de tres terminales de computadora diferentes en la oficina de Taylor en el Pentágono reflejó la

Cientos de destacados científicos estadounidenses sirvieron directamente a la administración

Importantes avances tecnológicos surgieron de un acuerdo similar entre las universidades y el

La nueva orientación de investigación básica y proyectos especiales de la agencia se adaptaba idealmente al

cinta magnética para su procesamiento, un lote a la vez. Dependiendo de la longitud de la cola y de la

compañero de resolución. En esta relación simbiótica estaba implícita la interdependencia de

Enseñarle a Lick a programar la máquina habría sido demasiado difícil.

Será una serie de comunicaciones de meses de duración entre candidatos, propagandistas,

eran esencialmente problemas de interacción persona­computadora. “Pensé que era simplemente

Detectar patrones de comportamiento entre funcionarios soviéticos de alto nivel. La computadora

Taylor era conocido por tener bastante intuición. Se le consideraba un responsable de

“¿Va a ser difícil hacerlo?” ­Preguntó Herzfeld.

Cuando Taylor asumió la dirección de IPTO en 1966, las manifestaciones de la filosofía de

“Sí, lo es”, respondió Herzfeld, un poco desconcertado.

"¿Quién es?" ­Preguntó Herzfeld.

Paul finalmente asistió a la escuela, a dos pasos de tranvía de su casa, en el Instituto de

Baran dejó Hughes a finales de 1959 para unirse al departamento de informática de la

Poco después de llegar a RAND, Baran desarrolló un interés en la capacidad de supervivencia de

En lugar de rehuir, Baran simplemente se sumergió más profundamente en su trabajo. RAND

Baran estaba trabajando en el problema de cómo construir estructuras de comunicaciones cuyos

Douglas Engelbart, científico informático del Instituto de Investigación de Stanford (SRI) en

Sin embargo, a pesar de la lógica de la recomendación de Clark, Roberts no podía simplemente

“¿Cuánto costará?” —le preguntó Beranek.

“Alrededor de 25.000 dólares”.

La presencia de un ordenador accesible inspiró un cambio en la empresa. Todos empezaron a pensar en

La evaluación de riesgos es esencial en cualquier empresa de ingeniería. Dado que ningún

“Sí, claro”, respondió Kahn. "¿Quién eres?"

La funcionalidad de la sofisticada capacidad de entrada/salida (E/S) de la computadora Honeywell

El equipo de BBN presentó su propuesta el 6 de septiembre de 1968, relativamente seguro de que

El concepto de conmutación de paquetes abrió un rico universo en el que un ingeniero capacitado y

Ciertamente se podría construir un experimento en red en un solo laboratorio, si así se quisiera.

"Willy, Frank dice que no deberías usar zapatillas en esta reunión".

La corrección de errores digitales se basa en la idea básica de la “suma de verificación”, un número

Si se escanea un producto y la computadora no emite un pitido, significa que la aritmética no se verificó.

Walden, Crowther y Cosell inventaron una forma inteligente de hacerlo.

eran esencialmente problemas de interacción personacomputadora. “Pensé que era simplemente

“¿Va a ser difícil hacerlo?” Preguntó Herzfeld.

"¿Quién es?" Preguntó Herzfeld.