Resumen

  • El RFC 1008 describe una confirmación opcional del control de flujo en el transporte ISO. Si un AK abre una ventana de crédito cerrada, el receptor puede repetirlo a intervalos cortos y solicitar al emisor una respuesta con el parámetro FCC.
  • Wayne McCoy escribió en junio de 1987 que no se había comunicado experiencia de uso con este procedimiento. Si la respuesta no llega, los reenvíos rápidos se detienen al alcanzar su límite y vuelve a mandar el temporizador normal de ventana.

Alguien espera a que termine una transferencia. La red está conectada, pero la barra imaginaria de progreso lleva demasiado tiempo inmóvil. En el ejemplo que estudia la guía, el receptor había agotado su capacidad y retirado el crédito; el emisor dejó de enviar datos. Más tarde se liberaron búferes. El receptor mandó un AK para anunciar que la ventana se abría. Ese pequeño mensaje se perdió. El emisor recuerda la última orden —esperar— y la cumple. El receptor tiene capacidad para recibir. El retraso nace de una noticia ausente, aunque ya haya espacio para el siguiente bloque.

Wayne McCoy explicó esa situación en el RFC 1008, una guía de implementación del protocolo de transporte ISO distribuida para recabar comentarios. Su sección sobre control de flujo distingue entre reconocer datos y comunicar una nueva capacidad de envío. Algunos mensajes AK merecen atención especial: los que reabren una ventana cerrada y algunos que llegan tras una reducción del crédito. Transportan permiso operativo, no sólo cortesía por un paquete recibido.

Si uno de esos AK desaparece, el receptor no pierde sus búferes libres. El emisor pierde el conocimiento de que existen. El temporizador de ventana puede reconciliar los estados más tarde, pero McCoy lo describió como relativamente largo. La confirmación FCC buscaba recortar ese intervalo. El receptor enviaría de nuevo el AK importante a intervalos breves y pediría confirmación de la información de flujo. Si el emisor respondía con un AK que incluyera FCC, cesarían los reenvíos rápidos.

La operación tenía freno. Sin respuesta, se alcanzaba el máximo de reenvíos y el temporizador ordinario volvía a dirigir la recuperación. FCC era opcional; el emisor no estaba obligado a contestar. McCoy propuso reutilizar para el modo rápido el propio reloj de la ventana, que mientras tanto se desactivaba. La descripción formal dibujaba dos relojes para explicar mejor la lógica. En su discusión de temporizadores, situó el intervalo rápido cerca de Erl + Elr, los retardos de los dos sentidos del trayecto.

¿Compensaba añadir ese intercambio? El manual pedía considerar cada caso: frecuencia de reducciones de crédito, probabilidad de perder TPDUs, duración del temporizador, tamaño de la ventana y estrategia de reconocimiento. Más mensajes consumen recursos; una pausa larga deja sin usar capacidad disponible. McCoy fue muy concreto sobre el estado de la evidencia: no había experiencia comunicada que demostrara si FCC y los reenvíos rápidos reducían la espera lo suficiente para justificar su implementación.

La escena puede contarse como un semáforo. Pasa a verde, pero el conductor no ve la luz. La solución propuesta era repetir la señal y escuchar si alguien confirmaba que la había visto. Mientras tanto, la persona que espera los datos sólo ve una transferencia detenida. La capacidad no falta; falta que el permiso llegue. Una ventana abierta de la que nadie se entera se parece mucho a una ventana cerrada, y los segundos de inactividad pueden acumularse hasta que despierte un temporizador largo.