Resumen

  • La extensión de fiabilidad parcial permitió a SCTP abandonar mensajes después de iniciar su transmisión, sin convertir toda la asociación en un servicio no fiable.
  • El abandono local y el avance del receptor son operaciones distintas. FORWARD TSN comunica qué posiciones ya no hay que esperar y ayuda a desbloquear mensajes ordenados.
  • Ni el contador de retransmisiones ni la duración asignada al mensaje prueban su recepción. Tampoco retiran una copia ya entregada a la aplicación.

Dos relojes pueden contar finales distintos

Imaginemos una copia que sigue en tránsito cuando el reloj del emisor vence. En el primer reloj, la persistencia ya terminó: no habrá otro intento. En el segundo, el receptor todavía puede aceptar esa copia antes de enterarse del abandono. No es una incidencia observada, sino el contrafactual que revela el límite del mecanismo: el plazo del emisor no es una fecha de caducidad sincronizada ni una orden de retirada.

La fiabilidad parcial del RFC 3758 no intenta hacer coincidir esos relojes. Separa tres momentos: dejar caducar antes de exponer un número, abandonar después de haber asumido una posición en la secuencia y, por último, autorizar al receptor a saltar esa posición. Cada etapa reduce una obligación distinta; ninguna certifica que el contenido llegó, se consumió o dejó de existir.

Primera etapa: caducar antes del TSN

Antes de asignar un número de secuencia de transmisión, el emisor comprueba la duración. Si el mensaje ya ha caducado, puede abandonarlo sin crear una posición que el receptor deba resolver y debería informar a la capa superior. Al no existir un TSN expuesto, no hace falta FORWARD TSN para explicar el hueco.

La comprobación no exige un despertador exacto por mensaje. Puede realizarse cuando el transporte va a numerar, transmitir o retransmitir, o en otros momentos convenientes. La aplicación no puede cambiar la duración después de entregar el mensaje a SCTP. El parámetro delimita el esfuerzo local, no un instante universal de invalidez.

Esta primera boca del embudo es estrecha: se descarta trabajo que todavía no había creado deuda de secuencia. Conviene distinguirlo de un paquete que simplemente no se observó en el receptor. «No enviado» es un estado de la tentativa del emisor, no una prueba sobre todos los ejemplares que pudieran existir en otro caso.

Segunda etapa: abandonar después del TSN

Una vez asignado el TSN, la caducidad antes de una transmisión o retransmisión obliga a aplicar las reglas de abandono. La decisión es por mensaje de usuario: si se abandona un fragmento, se abandonan todos los TSN de ese mensaje. No se mantiene la ficción de un mensaje completable tras retirar una de sus piezas.

Para su contabilidad, el emisor trata un TSN abandonado como «finally acknowledged» y deja de considerarlo pendiente. Pero no puede sumar esos bytes a partial_bytes_acked ni usarlos para ampliar la ventana de congestión. El cierre de una deuda de envío no es un recibo; si lo fuera, descartar datos crearía crédito para transmitir más.

El emisor conserva por ello dos referencias. La confirmación acumulativa real procede de los SACK del receptor. El Advanced.Peer.Ack.Point es una frontera local que incorpora abandonos. En el ejemplo del emisor del RFC 3758, el acumulativo está en 102, se abandonan 103 y 104, 105 sigue sin confirmación y sin abandono, y 106 está confirmado. El punto adelantado alcanza 104, pero no atraviesa el 105 fiable para llegar a 106.

La misma separación rige para políticas posteriores. El RFC 7496 permite limitar retransmisiones por bloque DATA; superar la cuenta para cualquiera de ellos abandona el mensaje entero, y cuentan tanto los reenvíos rápidos como los activados por temporizador. Un límite cero permite el primer envío y actúa cuando sería necesaria la primera retransmisión. También permite evacuar mensajes menos prioritarios cuando un nuevo mensaje necesita espacio en el búfer de la misma asociación, manteniendo los mensajes fiables por encima de los sometidos a esa política. Es prioridad de memoria local, no prioridad en la red.

Tercera etapa: autorizar el salto en el receptor

Cuando el punto adelantado supera el acumulativo realmente comunicado, FORWARD TSN transmite la frontera que puede dejar de esperarse. No puede franquear un TSN fiable sin confirmar que no se haya abandonado. Para datos ordenados añade la información de flujo y secuencia que libera mensajes retenidos; los datos sin orden no deben figurar en esas entradas.

El ejemplo del receptor es diferente del anterior. Su cumulativo está en 102; falta 103, están presentes 104 y 105, falta 106 y está presente 107. Una instrucción hasta 103 permite primero asumir la ausencia de ese bloque. La posesión real de 104 y 105 lleva después el acumulativo hasta 105. El 106 todavía detiene el avance. El embudo termina en progreso útil, pero no transforma el 103 ausente en datos recibidos.

El receptor debe además retirar todo reensamblado incompleto que dependa de un TSN ausente situado bajo la nueva frontera. Si ya había comenzado una entrega parcial, la capa superior debería saber que el mensaje no terminará. Un bloque que llegue tarde detrás de la frontera se trata como duplicado y se descarta; esa regla no revoca una entrega previa a la aplicación.

FORWARD TSN puede perderse. El emisor debe mantener activo el temporizador T3-rtx pertinente y revisar el avance al expirar. Una notificación antigua o igual a la posición actual no hace retroceder al receptor y puede provocar un nuevo SACK si el anterior se perdió. El abandono local, la autoridad enviada y el salto observado son tres hechos, no un único evento instantáneo.

La capacidad negociada precede al embudo

Nada de lo anterior puede imponerse a un par que no haya negociado la extensión. Una implementación capaz de usarla pero que no la anuncia debe actuar sin ella en esa asociación. Ante un par sin soporte, la capa superior puede abandonar el establecimiento o continuar con servicio fiable. Continuar no conserva por arte de magia la semántica de abandono prevista por la aplicación.

Este requisito deja la política en el emisor y la interpretación mínima en ambos extremos. El receptor no necesita saber si venció un plazo, se agotaron retransmisiones o faltó espacio en el búfer. Sí necesita haber aceptado la misma transición de secuencia. Esa es la razón por la que dejar de insistir requiere coordinación después de la numeración.

La historia llegó después del mecanismo

La especificación de octubre de 2000, el RFC 2960, ya incluía duración para datos en cola. Si el primer intento no empezaba a tiempo, podía cancelarse; si había empezado, el servicio fiable continuaba. Los RFC 4960 y RFC 9260 mantienen esa diferencia en la interfaz básica. Por eso no debe afirmarse que SCTP carecía de plazos antes de 2004 ni que toda asociación moderna activa fiabilidad parcial.

El documento informativo RFC 6458 describe una interfaz que selecciona política y valor, incluido el plazo temporal en milisegundos, sin prometer constantes o valores iniciales universales. Amplía la forma de pedir el servicio; no convierte la API descrita en un censo de implementaciones.

El RFC 8831 exige las variantes temporal y de retransmisiones limitadas para los canales de datos WebRTC. Allí, orden y fiabilidad son dimensiones separadas, y SCTP viaja sobre DTLS sobre ICE/UDP. Esa obligación pertenece al contrato de WebRTC; no demuestra adopción actual en un navegador concreto ni convierte la política por mensaje en atributo inmutable de todo flujo SCTP.

Vista como embudo, la innovación es más precisa que la palabra «caducidad». Antes del TSN, evita crear una obligación. Después del TSN, deja de perseguirla sin fingir recepción. En el receptor, crea una continuación compartida que conserva el hueco como hueco. Los dos relojes nunca tuvieron que marcar el mismo final.

Fuentes documentales

  • RFC 2960: duración inicial y comienzo de la transmisión.
  • RFC 3758: negociación, abandono y tratamiento de FORWARD TSN.
  • RFC 4960: interfaz de la especificación básica posterior.
  • RFC 6458: selección de políticas en una interfaz informativa.
  • RFC 7496: límites de retransmisión, prioridad y contadores.
  • RFC 8831: canales de datos WebRTC.
  • RFC 9260: SCTP básico en 2022.