Resumen

  • Las pasarelas podían reconstruir una ruta remota; el host debía detectar el caso que quedaba fuera de esa conversación: la pasarela inmediata muerta que ya no devolvía ningún aviso.
  • Un ICMP aislado durante la convergencia no justificaba por sí solo cerrar TCP. La retransmisión y el tiempo de usuario marcaban la gravedad; el error aportaba una causa probable.
  • El ACK de TCP no certificaba que SMTP hubiera aceptado el correo, y una sesión Telnet inactiva podía romperse sin activar ningún temporizador. La aplicación conservaba su propia decisión de finalización.

La pasarela que se llevaba consigo la explicación

RFC 816 describía una Internet en la que las pasarelas intercambiaban sus opiniones más recientes sobre la conectividad. Tras una avería podían discrepar durante un intervalo y, después, llegar a una topología coherente. Ese mecanismo permitía que una conexión sobreviviera a un cambio de camino sin que cada host se convirtiera en un sistema de enrutamiento completo.

La primera pasarela era la excepción. Si el host seguía entregándole datagramas después de que se hubiera apagado, no llegaba un Redirect ni un Destination Unreachable. La máquina muerta no podía emitirlos. Los demás routers podían haber encontrado ya una alternativa perfecta; los paquetes nunca alcanzaban ese nuevo mapa.

Clark redujo por ello la obligación del host a una tarea concreta: reconocer que el siguiente salto que utilizaba había dejado de funcionar y probar otra pasarela vecina. El fallo remoto quedaba en manos de quienes lo observaban de cerca. El fallo inmediato y silencioso quedaba en manos de quien todavía le entregaba tráfico.

La prueba era local y la decisión también. Cambiar el primer salto no autorizaba a declarar muerto el destino ni a cancelar la operación que se intentaba realizar allí.

Durante la convergencia, la verdad tenía fecha

ICMP Redirect comunicaba que existía una mejor pasarela inmediata. Destination Unreachable expresaba que, según el estado que conocía el emisor, el destino no podía alcanzarse. RFC 816 los trataba como mensajes de asesoramiento, no como sentencias sin caducidad.

Después de un corte, una pasarela podía haber aprendido la nueva ruta mientras otra aún conservaba la anterior. Un paquete enviado en ese intervalo podía provocar un Unreachable aislado aunque la red estuviera a punto de recomponerse. Cerrar una conexión establecida por esa única observación anulaba precisamente la capacidad de recuperación interna de Internet.

El mensaje seguía teniendo valor. Durante la apertura podía revelar una dirección inexistente. Después de un timeout podía orientar sobre la causa. Un Parameter Problem podía señalar una implementación defectuosa. Su peso dependía del tipo, el código, el momento, la fase de la conexión y la corroboración.

La alternativa no era creer o descartar. Era conservar la observación con su procedencia y permitir que la capa que conocía el propósito decidiera cuánto significaba.

Una corrección provisional podía corregirse a sí misma

El documento comparaba la detección proporcionada por la red, el sondeo continuo, el sondeo activado y la reselección activada. Enviar ICMP Echo todo el tiempo podía descubrir pronto un fallo, pero también cargar a los hosts, la red y las pasarelas. RFC 816 lo prohibía salvo que un análisis específico demostrara que el coste era aceptable.

El sondeo activado comenzaba después de una queja superior. Varias retransmisiones TCP podían avisar a IP, que entonces comprobaba la pasarela. Gastaba menos, aunque la confirmación podía llegar cuando TCP ya hubiera agotado su espera.

La reselección activada actuaba antes de disponer de un diagnóstico perfecto. IP elegía otra pasarela conocida. Si la primera estaba realmente muerta, recuperaba el tráfico antes. Si la sospecha era equivocada, la pasarela alternativa podía reenviar el paquete y devolver un Redirect hacia la mejor opción original.

No era una apuesta ilimitada, sino un ensayo reversible. La incertidumbre autorizaba una acción local de bajo alcance, no una política permanente.

RFC 1122 convirtió la detección de un siguiente salto muerto y la elección de una alternativa en requisito para IP. También reconoció que no existía un algoritmo universal completamente satisfactorio, mantuvo la prohibición del ping continuo y prefirió el consejo cruzado de TCP, enlace, ARP e ICMP.

TCP sabía que no avanzaba, no necesariamente por qué

Ante un segmento sin confirmar, TCP retransmitía hasta recibir el ACK o alcanzar su límite. La repetición podía dar a IP una señal negativa sobre la ruta. En dirección contraria, IP entregaba a TCP los errores ICMP y los informes de la red conectada.

La retransmisión constataba falta de progreso. El tiempo de usuario definía cuándo el cliente ya no quería esperar. El mensaje de error sugería una explicación. RFC 816 pedía que esas piezas llegaran a la aplicación porque una persona en Telnet y un programa de correo no tomaban la misma decisión ante la misma demora.

RFC 1122 exigió que ciertos errores blandos no abortaran una conexión TCP establecida y que la información estuviera disponible para la aplicación. RFC 5461 mostró el intercambio: la paciencia conserva sesiones durante fallos transitorios, pero puede retrasar el intento de otra dirección cuando la primera es permanentemente inaccesible. Los atajos que documentó para el establecimiento no modificaron la reacción estándar.

RFC 9293 todavía distingue el timeout de retransmisión del timeout de usuario. El primero reenvía; el segundo vacía las colas, notifica el aborto, elimina el estado y cierra. Compartir la palabra «tiempo» no convierte ambas acciones en la misma autoridad.

Recibir bytes no era terminar el trabajo

En algunos receptores de correo tempranos, el proceso se bloqueaba después de recibir todo el texto y antes de devolver el acuse SMTP. TCP ya había confirmado los bytes; no quedaban datos pendientes capaces de activar su temporizador. El emisor esperaba una conclusión que sólo SMTP podía producir.

Un temporizador de aplicación resolvía una parte del problema, pero su duración dependía del trabajo. Un plazo corto daba falsos fallos con mensajes grandes y hosts lentos. Uno largo detectaba tarde el bloqueo real. Algunos programas ajustaban la espera al tamaño del mensaje. La lección era que la capa que conocía la operación debía definir qué respuesta y qué demora tenían sentido.

Telnet mostraba la situación inversa. La ruta podía morir mientras el usuario pensaba. Sin tráfico ni datos pendientes, el servidor no veía una retransmisión fallida y podía conservar para siempre una sesión inútil. Una prueba de presencia podía ayudar, pero aplicada con demasiada frecuencia a todos los usuarios repetía el coste del sondeo continuo.

En un caso, TCP había tenido éxito sin que la aplicación terminara. En el otro, no tenía trabajo activo con el que detectar la rotura. Ninguno permitía delegar la verdad final a la capa de transporte.

El consejo era útil porque tenía límites

RFC 816 ensambló una cadena de hechos parciales. El sistema de rutas atendía la avería distante; el host cambiaba un primer salto silencioso; TCP exponía el estancamiento y el fin de la paciencia; la aplicación certificaba su operación.

Un error podía ser correcto sin ser definitivo. Un timeout podía ser decisivo sin diagnosticar la causa. Un ACK podía ser auténtico sin constituir un recibo de negocio. Mantener esas diferencias permitía reaccionar rápido y, a la vez, sobrevivir a señales transitorias o contradictorias.

El mensaje de error no perdió valor al quedar como consejo. Ganó una función precisa: aportar contexto sin apropiarse de la decisión que todavía pertenecía a otra capa.

Fuentes