Resumen

  • DCCP asigna números de secuencia a todos los paquetes, incluidos los de confirmación. Un hueco no demuestra por sí solo cuántos datos de la aplicación se perdieron.
  • CCID 2 conserva y repite información de recepción hasta que el emisor confirma un informe. El objeto que se libera es el historial del receptor, no una copia de datos pendiente de retransmisión.
  • La pérdida de esa segunda confirmación prolonga la conservación; no exige una tercera. El mecanismo cambia con el perfil de congestión y con el paso de tráfico bidireccional a unidireccional.

Contar paquetes no era contar contenido

El RFC 4340, publicado en marzo de 2006, hacía avanzar la secuencia de DCCP con cada paquete. Un DCCP-Ack sin datos consumía un número igual que un paquete de datos. Así era posible detectar pérdidas en el canal que informaba de otras pérdidas.

El precio de esa visibilidad era una ambigüedad. Si faltaban tres números, podían corresponder a tráfico de control. La aplicación no tenía derecho a convertirlos automáticamente en tres unidades de contenido perdido.

La opción NDP Count ayudaba a resolver una parte del problema. Cuando se habilitaba la función correspondiente, informaba de la longitud de la serie de paquetes sin datos inmediatamente anterior. Si después de un hueco de K números aparecía un recuento de al menos K, el hueco estaba formado por paquetes sin datos según ese mecanismo.

No era un inventario de bytes perdidos ni una reconstrucción completa de una ráfaga que mezclara clases. Además, la clasificación de Request y Response como paquetes de datos no garantizaba que todos llevaran carga de aplicación. El protocolo ofrecía una observación delimitada, no una licencia para convertir cualquier contador en una medida de servicio.

La aplicación podía preferir el siguiente instante

La distinción tenía sentido dentro del problema que DCCP trataba de resolver. El RFC 4336 describía aplicaciones interesadas en datagramas sujetos a control de congestión, pero no en la recuperación obligatoria de cada contenido anterior.

En una conversación de voz, un fragmento que llega después de su momento de reproducción puede carecer de utilidad. En un juego, la posición actual puede importar más que recuperar una posición antigua. El control de congestión limita las oportunidades de envío; la aplicación quiere decidir qué información merece ocupar la siguiente.

DCCP no retransmite los datos de aplicación perdidos. Eso no impide que una aplicación añada su propia recuperación selectiva. Lo que evita es imponerle, desde el transporte, la reconstrucción de una secuencia completa de contenidos aunque algunos ya hayan caducado.

Pero el emisor necesita conocer las pérdidas y las señales de congestión para ajustar su comportamiento. Con CCID 2, la información de recepción se comunica de forma fiable. Se había separado la fiabilidad de los datos de la fiabilidad del conocimiento necesario para compartir la red.

Un número alto no cerraba todos los huecos

El campo de confirmación de DCCP indica el mayor número de secuencia recibido. No significa que todos los números anteriores hayan llegado, como tampoco cuenta el próximo byte esperado en un flujo TCP. Los huecos intermedios se explican mediante opciones.

Ack Vector representa una historia que empieza en ese número y retrocede. Cada byte dedica dos bits al estado y seis a la longitud de una serie. La longitud cero significa un paquete; 63 significa 64. Los estados distinguen recibido, recibido con marca ECN, reservado y todavía no recibido.

Una sucesión larga de recepciones iguales puede describirse con pocos bytes. Sin embargo, la compresión no resuelve cuándo termina la obligación de conservarla. El receptor puede haber enviado esa descripción sin que el emisor la haya visto.

También importa lo que significa «recibido». DCCP ha procesado las opciones y puede confirmar el paquete; no hace falta que la aplicación haya consumido los datos. Una pérdida en el búfer de recepción de la aplicación sigue comunicándose con el estado de recepción adecuado. Data Dropped permite añadir otra información sin inventar una pérdida en el trayecto de red.

El vocabulario técnico funciona porque cada término resuelve una pregunta concreta. Si «recibido» pretendiera certificar a la vez tránsito, almacenamiento y uso, dejaría de ser una entrada clara para el control de congestión.

El informe que necesitaba una salida

El receptor mantiene una ventana de información pendiente: la que ha anunciado sin saber si llegó, junto con la que todavía no ha anunciado. Nuevos paquetes amplían esa ventana. La confirmación de un informe permite retirar la parte antigua.

Sin una señal de cierre, un receptor CCID 2 podría terminar repitiendo información desde el comienzo de la conexión. No basta con saber que salió un Ack Vector. Es necesario saber qué Ack Vector recibió el otro extremo.

Aquí cobra utilidad que el propio informe tenga número de secuencia. El emisor puede citar ese paquete al confirmar su recepción. El receptor relaciona la confirmación con la historia que había incluido y obtiene una base para liberar estado.

No está esperando una autorización para abandonar los datos perdidos de la aplicación. DCCP ya no se había comprometido a retransmitirlos. Lo que está cerrando es una obligación distinta: seguir haciendo llegar la información que necesita el control de congestión.

Cuando el tráfico deja de ser simétrico

Mientras ambas aplicaciones envían datos, las confirmaciones necesarias suelen viajar dentro del intercambio ordinario. La dificultad aparece cuando B deja de enviar datos pero sigue recibiendo los de A. B continúa enviando informes; A ya no tiene datos de B que confirmar de la manera habitual.

El RFC 4341 exige al emisor activo confirmar ocasionalmente los informes de su receptor. Puede hacerlo usando DCCP-DataAck en lugar de DCCP-Data. Recomienda hacerlo al menos una vez por ventana de congestión, no después de cada confirmación individual.

Si las dos aplicaciones callan, el emisor puede esperar indefinidamente antes de confirmar. Esa posibilidad no debe confundirse con el comportamiento exigido cuando sigue enviando datos activamente. Las obligaciones dependen de lo que sigue ocurriendo en cada sentido.

La detección de quietud en CCID 2 tampoco consiste en esperar siempre 200 milisegundos. El intervalo es el mayor entre 0,2 segundos y dos tiempos de ida y vuelta. Además, el emisor debe haber confirmado los vectores que cubren todos los datos recibidos. Con el RTT predeterminado de 0,2 segundos cuando no se conoce, el segundo término asciende a 0,4 segundos.

El perfil de un sentido define cuándo ese sentido está quieto; el del sentido opuesto determina cómo se gestionan entonces las confirmaciones de informes. Un indicador genérico de conexión inactiva puede ocultar esa división de funciones.

La cadena se detenía por una diferencia de consecuencias

¿Quién confirma la confirmación del informe? Nadie tiene que hacerlo de manera fiable. Si ese segundo mensaje se pierde, el receptor guarda y repite su información durante más tiempo. La pérdida retrasa la limpieza, pero no le induce a creer que una noticia desconocida ya fue recibida.

Por eso no hace falta una tercera capa. El diseño no intenta obtener certeza infinita acerca de todas las transmisiones; identifica qué incertidumbre puede convertirse en conservación adicional. Las pérdidas siguen teniendo costes, pero no todas generan una nueva promesa de entrega.

La limpieza necesita otra cautela cuando un paquete llega tarde. Si el receptor ya había informado de su ausencia, confirmar aquel informe no confirma la noticia posterior de su llegada. La implementación ilustrativa del apéndice A.3 del RFC 4340 limita la frontera de liberación para que la nueva información no desaparezca antes de ser comunicada.

Ese apéndice no obliga a usar un búfer concreto. Muestra por qué la frontera debe corresponder a lo que el otro extremo sabe, no simplemente a la antigüedad del registro. La combinación de estados también debe tolerar informes reordenados: una noticia vieja de ausencia no puede borrar sin más una recepción ya conocida.

No todos los perfiles conservaban la misma historia

El RFC 4342 define CCID 3 mediante TFRC. Su preferencia por cambios de tasa más suaves tiene como contrapartida una respuesta más lenta a variaciones de capacidad. El RFC de base señala que su estado de confirmación está generalmente acotado, por lo que no necesita la misma confirmación de confirmaciones. No significa que carezca de memoria o de información de retorno.

Sus erratas verificadas corrigen, entre otras cosas, el intervalo para medir la tasa recibida: el último RTT, no todo el tiempo desde el informe anterior. Si un segundo Receive Rate se ignora en el caso permitido de un intervalo sin datos, tampoco debe reiniciarse el temporizador de ausencia de información. Un paquete de control no siempre aporta una observación que justifique renovar el plazo.

Las erratas del RFC 4340 corrigen un ejemplo que trataba indebidamente como inválido el valor cero de Ack Ratio, además de detalles del apéndice. En 2018, el RFC 8311 retiró la discusión de ECN Nonce de tres perfiles DCCP. La historia no debe presentar cada frase del texto de 2006 como instrucción vigente.

El RFC 6773 había añadido en 2012 encapsulación UDP para atravesar determinadas limitaciones de equipos intermedios. Adaptar el envoltorio no convertía DCCP en transporte fiable de datos. Y los identificadores de IANA documentan asignaciones, no cuántos sistemas los utilizan hoy.

La aportación que se puede establecer con estas fuentes es más pequeña que una historia de triunfo comercial y más precisa que una comparación de velocidades. DCCP permitió que un servicio de datos no fiable mantuviera un intercambio fiable de conocimiento, y diseñó la forma de dejar de conservarlo sin confundir el final de un informe con el final de todos los riesgos.