Resumen

  • El RFC 1152, de abril de 1990, conserva las discusiones de un taller sobre redes de muy alta velocidad. David Clark planteó que los protocolos existentes podían alcanzar un gigabit por segundo si esa era la única meta; distancia, usuarios y servicios exigían preguntas adicionales.
  • Keith Lantz llevó a la sala la videoconferencia y sus flujos sincronizados. Craig Partridge mostró el coste creciente de esperar una llamada remota. El prototipo Nectar reveló, en cifras preliminares, que la interfaz del ordenador podía reducir lo que recibía la aplicación.

El usuario no vive dentro del cable

El Internet Research Steering Group, dentro del entorno de la IRTF, patrocinó el taller. Craig Partridge armó el informe con las notas de los responsables de cada sesión, revisadas por los participantes. Sus páginas no describen una votación para elegir el futuro; enseñan un conjunto de desacuerdos productivos. El primero era sobre la propia pregunta: ¿se trataba de hacer más rápido un protocolo o de sostener servicios nuevos a larga distancia y para mucha gente?

David Clark abrió la sesión de implementación con una provocación técnica. Según él, los protocolos existentes podían moverse a un gigabit por segundo si bastaba con alcanzar esa tasa. Los proyectos reales añadían reserva de capacidad, recorridos largos y muchos usuarios. La decisión sobre la arquitectura dependía de esos requisitos completos. Los ponentes presentaron desde procesadores especializados hasta maneras más eficaces de ejecutar protocolos conocidos. Cada solución cobraba un precio distinto en complejidad.

Keith Lantz llevó después el debate a la mesa de trabajo. Su «oficina portátil» prometía acceso a las mismas personas y servicios desde casa, la empresa o un lugar distante. Portátil era la posibilidad de seguir trabajando, no solo el peso de un ordenador. En una conferencia de escritorio convivían texto, gráficos, audio y vídeo. Sus flujos necesitaban anchos de banda muy diferentes, retraso bajo y, en ciertos casos, poca variación de ese retraso. También debían mantenerse sincronizados. Una conexión capaz de transportar imágenes a gran velocidad sigue dando una conversación ridícula si la voz llega fuera de tiempo.

Lantz pidió además adaptación a tramos más lentos, congestión y cambios aceptables en la calidad de imagen. Una sesión puede atravesar una ruta desigual. Diseñar para su mejor tramo deja al usuario a merced del peor. La pregunta útil pasa a ser qué forma conserva el servicio cuando baja la capacidad disponible.

La luz no acorta el viaje de vuelta

En la sesión de sistemas distribuidos, Partridge se ocupó de las llamadas a procedimientos remotos. Los procesadores mejoraban deprisa; la latencia de ida y vuelta entre lugares lejanos seguía ligada a la distancia. Cada espera representaba así más ciclos de trabajo desaprovechados. Paralelizar llamadas aumentaba las tareas en marcha, pero una secuencia que dependía de una respuesta tenía que recibirla antes de seguir.

El caché ofrecía ayuda y otra factura. A medida que se multiplicaban las copias guardadas, mantenerlas coherentes podía exigir nuevas comunicaciones. El sistema terminaba haciendo llamadas de sincronización para ahorrarse llamadas normales. Partridge prefería agrupar varias operaciones destinadas a la misma máquina en un encargo mayor. Otros defendían la anticipación o formas de programación asíncrona. El informe dejó visibles esas alternativas, con sus diferentes maneras de pagar por el tiempo.

Una demostración del taller situó el obstáculo dentro del propio ordenador. Según los resultados preliminares del proyecto Nectar de Carnegie Mellon, procesos ejecutados en sus tarjetas de comunicación intercambiaban datos a 70 Mbps; los procesos en los anfitriones quedaban cerca de 25 Mbps por el límite de la interfaz VME. Esa relación describe aquel prototipo, no una ley universal. Jeff Mogul añadió que mover paquetes a la caché del procesador y avisar al programa podía resultar más costoso que ejecutar el protocolo. El paquete había llegado por la red, pero todavía tenía que entrar en la aplicación.

El taller dejó una tarea menos vistosa que vender gigabits: seguir el tiempo completo de una acción. Incluía la espera de respuesta, la coordinación entre medios, el segmento lento y la entrega al proceso. El cable corría. La tarea, en cambio, podía quedarse haciendo cola.