Resumen

  • RFC 3366 trató la persistencia del ARQ de enlace como un presupuesto de tiempo: cuánto se intenta recuperar una trama antes de abandonar. No es un aumento gratuito de fiabilidad.
  • Una retransmisión puede ayudar a un flujo mientras añade demora acumulada, fluctuación o bloqueo a los demás; el acuse de una trama no prueba que la aplicación recibiera datos a tiempo.

Una trama no es un paquete completo

La historia empieza por debajo de IP. Automatic Repeat reQuest, o ARQ, detecta una trama perdida o corrupta y vuelve a transmitirla. Según el enlace, una trama puede transportar un fragmento de un paquete IP, un paquete completo o partes de varios. El acuse responde a una pregunta limitada: ¿aceptó la trama el protocolo local del enlace? No certifica que el paquete llegara de extremo a extremo ni que aún sirviera a la aplicación.

Publicado como Best Current Practice 62, RFC 3366 pidió a los diseñadores tomar en serio ese límite. No definía una radio concreta ni prescribía un número único de intentos. Explicaba cómo un mecanismo local de reparación interactúa con el tráfico de Internet que circula por encima.

El presupuesto de reintentos gasta tiempo compartido

El documento llama «persistencia» a la disposición a volver a intentarlo. Un enlace puede permitir un número fijo de intentos o dejar que temporizadores y procedimientos de fallo determinen cuándo se detiene. El número de intentos no es un reloj: la propagación, la espera por el medio compartido, las colas, el tamaño de la trama y el procesamiento cambian el tiempo transcurrido.

Por eso la fiabilidad es condicional. Un enlace suele reaccionar antes que el control de extremo a extremo de TCP y puede reparar un error de canal antes de que retransmita el emisor. Pero la trama recuperada puede llegar con suficiente demora para afectar el temporizador de transporte. Si el enlace conserva el orden, los paquetes completos posteriores pueden quedar detrás de una trama que aún se reintenta. En un canal compartido, esos intentos también consumen tiempo de transmisión que necesitaban otros nodos.

La persistencia perfecta muestra el contraste: seguir intentándolo indefinidamente mientras el receptor aún pueda aceptar la trama. Puede servir en una transferencia cuyo objetivo sea una entrega fiable. Sin embargo, en una ruta con varios enlaces la reparación repetida puede duplicar trabajo ya previsto de extremo a extremo; no garantiza la misma fiabilidad que el transporte entre los extremos. En streaming y otras aplicaciones UDP sensibles al tiempo, un paquete tardío quizá sea menos útil que uno perdido.

Lo que el enlace puede saber sin adivinar

Es tentador asignar persistencia larga al tráfico que «parece fiable» y corta al resto. RFC 3366 explica por qué observar no basta. El enlace puede ver conducta de control de congestión sin conocer el plazo de la aplicación ni si prefiere integridad o actualidad. Los puertos pueden inducir a error o ser remapeados; los túneles agrupan flujos distintos; el cifrado limita la inspección; y una marca de servicio puede sobrescribirse o tener un significado solo local.

La recomendación es condicional. Si el enlace puede distinguir clases de servicio con seguridad, diferentes políticas de reintento pueden ayudar. Si no, todos heredan la misma conducta. Cuando no es viable clasificar, el BCP suele favorecer una persistencia baja: recuperar algunas tramas sin dejar que un paquete incompleto retenga la cola indefinidamente. El documento también mantiene la excepción: una persistencia alta puede ayudar a TCP en ciertas condiciones de errores variables o tras una interrupción transitoria. No existe un ajuste óptimo para todos los casos.

RFC 3819, una guía más amplia de diseño de subredes publicada en 2004, extiende el marco a tres costes relacionados: pérdida, demora media y variación de la demora. Refuerza la flexibilidad; no convierte el ejemplo de dos a cinco intentos en una regla moderna ni en una medición de lo que despliegan las redes.

El acuse sigue siendo local

La lección duradera de RFC 3366 también trata sobre evidencia. Un ACK de trama registra un suceso local. La salida del paquete del enlace, su aceptación por el transporte y su llegada a tiempo a la aplicación son sucesos posteriores que requieren pruebas propias. Retransmitir puede reducir pérdidas de canal y, al mismo tiempo, aumentar la fluctuación, retrasar información de congestión o consumir el tiempo de otros flujos.

El diseñador elige un presupuesto local; la ruta acumula sus efectos. Sin conocer el resto del camino ni la necesidad de actualidad de la aplicación, un equipo no puede convertir «más intentos» en una promesa de mejor servicio. El BCP 62 pidió incorporar esa incertidumbre al diseño, no ocultarla bajo la etiqueta de fiabilidad.

Fuentes

Lu Heng no escribió RFC 3366. Estos ensayos se identifican como lentes analíticas para distinguir entre recomendación, implementación, configuración y resultado observado.