Resumen

  • RFC 872 sostuvo que una red local rápida y con pocos errores no volvía inapropiado a TCP por definición. Había que empezar por la entrega que esperaba cada aplicación.
  • UDP y el acceso directo a funciones de la red local ofrecían opciones para tareas concretas; una segunda pila local exigía construcción y mantenimiento junto a la usada para llegar a otras redes.

Un cable corto tiene aspecto de atajo. En septiembre de 1982, Michael A. Padlipsky vio que algunos ingenieros convertían ese atajo en una teoría completa: TCP, pensado para enlazar máquinas a través de redes, sería demasiado pesado dentro de una LAN. Su RFC 872 llamó Woozle al miedo que crecía al repetirse. La criatura imaginaria aparecía en la conversación técnica; en el laboratorio seguían estando el cable, dos equipos y una aplicación que quería hacer algo preciso.

Padlipsky delimitó primero la LAN de la que hablaba. Era un mecanismo de comunicación de corta distancia, relativamente rápido y con pocos errores, al que podían conectarse máquinas distintas para intercambiar datos y compartir recursos. Admitía varias formas y medios físicos. Lo importante era la comunicación entre computadoras. Una instalación de terminales que permitía entrar en varios equipos, sin protocolos para que esos equipos dialogaran entre sí, merecía otra descripción en su análisis. La distinción evitaba premiar al enlace por servicios que en realidad debía prestar el software de los extremos.

TCP ofrecía una conexión lógica fiable, control de flujo y entrega en orden. Un programa que necesitaba recibir un archivo completo seguía necesitándolo aunque el otro equipo estuviera en el pasillo. El enlace corto podía cometer menos errores y transportar bits deprisa. La aplicación continuaba esperando la misma secuencia de datos. La ubicación del vecino no aprobaba automáticamente una excepción a su contrato.

Después venía IP, que Padlipsky trató como una pieza separada. IP determinaba si el destino estaba en la red próxima o si el paquete debía ir a una pasarela. También se ocupaba de cruzar redes que aceptaban tamaños de paquete distintos y de identificar el protocolo superior al que debía entregar cada paquete. Al quedar separado de TCP, otros protocolos entre equipos podían aprovecharlo. Para una máquina que tuviera que hablar con el exterior, la LAN era el primer tramo de un trayecto mayor. Que ese primer tramo fuera rápido no volvía innecesario saber cómo salir de él.

El ensayo dejaba espacio para otras decisiones. UDP podía servir a una tarea como la voz dividida en paquetes, donde una aplicación valoraba la rapidez y podía prescindir de las propiedades de TCP. También cabía explotar directamente capacidades locales en un diseño adecuado. El coste surgía cuando el equipo mantenía una pila especial para la LAN y otra para comunicarse con el resto de redes. Había que conservar código, corregir fallos y explicar dos juegos de reglas en los mismos computadores. El monstruo TCP podía resultar más barato que el plan para esquivarlo.

La objeción sobre rendimiento merecía una prueba real. En una red local con pocos errores, la suma de comprobación de TCP parecía a algunos una ceremonia de más. Padlipsky informó de mediciones en varios tipos de equipo de la comunidad de investigación: el cálculo representaba solo una parte del tiempo de procesamiento por transmisión en esas implementaciones. Era un dato situado en 1982, no una cifra para cualquier máquina futura. Había que medir la tarea entera. El disco debía entregar datos, el sistema operativo preparar buffers y el programa consumir el resultado.

Un cable veloz podía pasar buena parte de su jornada esperando al anfitrión.

Padlipsky recordó que TCP/IP ya funcionaba en diversos sistemas operativos y que había aplicaciones compatibles implementadas. Al mismo tiempo pidió medir cuidadosamente el rendimiento en LAN. Una ruta local específica podía ganar cuando una tarea y una comparación justa lo justificaran. La prueba debía incluir la misma calidad de servicio y el esfuerzo de mantener la alternativa. Un número de velocidad del medio, aislado del trabajo del computador, daba una respuesta demasiado pequeña.

La RFC 872 conserva el debate de 1982 en su forma más útil: ¿qué propiedades pide la aplicación, hasta dónde necesita hablar el equipo y qué componente limita de verdad la transmisión? La pregunta adecuada hizo un trabajo bastante más barato que alimentar al monstruo.