Summary

  • RFC 5238 pide evitar la retransmisión de una solicitud que DCCP ha encolado pero aún no ha transmitido; cuando la interfaz lo permite, el reloj DTLS puede comenzar al entregar el mensaje a IP.
  • Admisión, entrega inferior, emisión, recepción, final de DCCP, progreso de DTLS y disponibilidad de la aplicación son acontecimientos diferentes y no deben compartir un único indicador de éxito o pérdida.

La cola fabricó una pérdida

DTLS entrega un registro al transporte. DCCP lo acepta, aunque el control de congestión aplaza su salida. Si el plazo superior comienza con la aceptación, su expiración mezcla espera local y viaje de red. La métrica parece demostrar pérdida sin que el original haya salido.

El reintento ocupa después la misma capacidad escasa. Retrasa al original y convierte ese nuevo retraso en argumento para otra copia. La observación empieza a producir la condición observada.

RFC 5238 recomienda una señal más fiel: esperar, si DCCP puede informarlo, hasta que el mensaje se transfiera a la capa IP.

La fiabilidad no atraviesa automáticamente las capas

DCCP y DTLS tienen sendos procesos de establecimiento. Pueden ejecutarse en serie o solaparse parcialmente si registros DTLS viajan dentro de DCCP-Request y DCCP-Response.

Sin embargo, la fiabilidad del establecimiento DCCP no garantiza los datos de aplicación incorporados. El servidor puede descartarlos y una retransmisión de la solicitud puede omitirlos. DTLS conserva por ello su propia recuperación.

Ese registro superior no puede volver a salir como dato ordinario hasta que termine el establecimiento DCCP. El estándar ordena esperar antes de reiniciar el temporizador DTLS para que no se acumulen copias que todavía no pueden transmitirse.

Dos relojes parecidos no son un mismo reloj

Ambas capas emplean plazos y retroceso. Cada una protege un sujeto distinto. La expiración de DCCP no prueba el estado del vuelo DTLS, y la espera de DTLS no identifica por sí sola una pérdida en la red.

Un establecimiento DTLS grande puede quedar limitado por el control de congestión hasta activar el reintento superior. Añadir tráfico puede empeorar la situación. Esto no invalida la retransmisión: distingue la recuperación después de una falta de respuesta de la duplicación antes de una salida demostrada.

El inicio del reloj define la pregunta. La admisión mide servicio solicitado; la entrega a IP mide tiempo desde que la capa inferior liberó el intento. Solo la segunda se aproxima al plazo de respuesta de red que se pretende gobernar.

Los números conservan su ámbito

RFC 5238 afirma que el número de secuencia DCCP no está conectado con el del registro DTLS y que la sincronización DCCP no equivale a protección antirrepetición DTLS. Compartir un paquete no comparte semántica.

La regla de tamaño también depende del estado actual. Cada registro DTLS debe caber en un paquete DCCP y no superar el máximo vigente, que puede variar con la congestión. La aceptación previa no garantiza capacidad futura.

El establecimiento deja una herencia

El tráfico de negociación puede cambiar el estado con que comienza la aplicación. Bajo CCID 2, una negociación grande puede provocar una disminución multiplicativa y dejar el flujo posterior esperando recuperación aditiva. RFC 5238 invita a considerar CCID 3 cuando conviene una variación más suave.

No es una clasificación universal de perfiles. «Seguridad establecida» y «régimen de congestión adecuado para la carga» son dos conclusiones distintas.

Lo que las fuentes no prueban

No hay producto actual, despliegue, traza, interrupción ni rendimiento medido. IANA registra parámetros, no uso. Las versiones posteriores de DTLS son historia normativa y no prueban adopción sobre DCCP.

La entrega a IP tampoco demuestra emisión física, recepción remota o sesión lista. Es un comienzo más defendible que la simple entrada en una cola, no el final de la cadena.

Un recibo para cada frontera

Registre solicitud, admisión, decisión del controlador, entrega a IP, identidad de secuencia, emisión observable, respuesta, estado DCCP, vuelo DTLS y liberación de la aplicación. Asigne cada temporizador a un componente y documente qué lo inicia, pausa y cancela.

Mientras la capa inferior declare que el original sigue en cola, suprima copias superiores. Conserve respuestas tardías, cancelaciones y reemplazos para que no se transformen retrospectivamente en «pérdida de red».

La doctrina de Lu Heng exige realidad ejecutada: una API que acepta trabajo no demuestra que el trabajo salió. Quien configura el plazo debe responder por la frontera, porque el reloj crea tráfico además de medir espera.

Sources

Registro normativo adicional

  1. Texto de RFC 5238
  2. Ficha de RFC 5238
  3. RFC 5238 en Datatracker
  4. Historial de RFC 5238
  5. Erratas de RFC 5238
  6. Documentos que citan RFC 5238