Resumen

  • RFC 3758 dejó el criterio para abandonar cada mensaje en la política del servicio y definió FORWARD TSN como señal genérica para recuperar el avance.
  • La fiabilidad temporizada no obliga a la pila SCTP a evaluar cada mensaje justo en el instante en que vence su plazo.

El reloj llegó a cero, pero SCTP podía mirar el mensaje en otro momento. RFC 3758 permite esa diferencia entre el vencimiento nominal y la comprobación efectiva.

La extensión de fiabilidad parcial no convirtió SCTP en un transporte sin reglas. Permitió que una aplicación decidiera, mensaje por mensaje, cuánto debía persistir el intento de envío o retransmisión. Cuando ambos extremos anuncian compatibilidad durante el establecimiento de la asociación, el emisor puede dejar de perseguir algunos datos y enviar FORWARD TSN. El receptor actualiza su punto acumulativo de números de secuencia de transmisión (TSN) y, en mensajes ordenados, recibe también información de secuencia por flujo para liberar datos que estuvieran retenidos detrás del hueco.

La política y la señal cumplen funciones distintas. El receptor no necesita saber si el emisor abandonó por antigüedad, por un límite de retransmisiones o por otra regla. Necesita saber qué espacio de secuencia debe dejar de esperar y qué mensajes ordenados pueden volver a ser elegibles para entrega. FORWARD TSN no transporta el razonamiento de la aplicación; transporta la instrucción mínima para que la secuencia avance.

La diferencia entre la SCTP original y el servicio temporizado muestra por qué importa esa separación. En la base descrita por RFC 2960, el parámetro de vida útil podía evitar que un mensaje todavía no transmitido saliera tarde. Pero si la primera transmisión había ocurrido antes del vencimiento, el mensaje pasaba a ser fiable normal y debía seguir retransmitiéndose. RFC 3758 eliminó esa restricción para el servicio de fiabilidad temporizada: un mensaje ya transmitido también podía abandonarse después de vencer.

Eso no significa que el cambio de estado ocurriera necesariamente en el instante exacto del vencimiento. Las reglas piden evaluar la vida útil antes de asignar un TSN y antes de transmitir o retransmitir un mensaje que ya tiene TSN. A la vez, el documento explica que no hace falta mantener un temporizador separado para cada mensaje. La implementación puede aprovechar puntos de trabajo existentes —asignación, transmisión o vencimiento de un temporizador de retransmisión— y el emisor puede evaluar la vida útil en otra ocasión conveniente. No tiene obligación de consultar cada mensaje en el mismo milisegundo en que vence.

Así, una API que acepta un parámetro de vida útil no basta para afirmar que ofrece una fecha límite estricta de entrega o de abandono. Puede definir cuándo la transmisión deja de ser admisible una vez que la pila evalúa el mensaje; el momento de evaluación depende del procesamiento de la pila. Una aplicación sensible al tiempo debe tratar ese matiz como parte del contrato, no como un detalle invisible del protocolo.

También importa cuándo el mensaje recibió TSN. Si caduca antes de esa asignación, puede abandonarse sin dejar un hueco que el receptor deba saltar. Si el TSN ya existe, el emisor marca los datos como abandonados y puede necesitar FORWARD TSN. Si se abandona un fragmento de un mensaje fragmentado, RFC 3758 exige abandonar juntos sus demás fragmentos. El espacio TSN es común a la asociación; las secuencias de mensajes ordenados pertenecen a cada flujo. El chunk permite que ambos niveles progresen sin fingir que la carga faltante llegó.

FORWARD TSN no es un acuse de entrega. Indica que el emisor dejará de retransmitir determinados números y pide al receptor que avance más allá de ellos. No demuestra que el mensaje abandonado llegara, que el siguiente mensaje fuera aceptado por la aplicación o que un servicio cumpliera un plazo de extremo a extremo. La congestión tampoco desaparece: los datos abandonados no aumentan la ventana de congestión y los eventos que habrían provocado una retransmisión conservan sus ajustes correspondientes.

La compatibilidad de la asociación es otra condición. Si el par no anuncia soporte de FORWARD TSN, no se puede usar la extensión en esa asociación. Una aplicación que dependa de ella debe conocer el resultado de la negociación y decidir si cancela, cambia de política o continúa sin fiabilidad parcial. La función disponible en un extremo no prueba que el otro acepte el mismo modo.

RFC 7496 añadió más tarde políticas de número limitado de retransmisiones y de prioridad. Esas variantes refuerzan el diseño: puede cambiar la regla que decide abandonar, mientras el mecanismo de avance de secuencia sigue siendo común. La política pertenece al servicio; el hueco y la señal pertenecen al transporte.

Fuentes