Protocolo de control de congestión de datagramas

En redes informáticas , el Protocolo de control de congestión de datagramas ( DCCP ) es un protocolo de capa de transporte orientado a mensajes . El DCCP implementa la configuración y desconexión de conexiones confiables, la notificación explícita de congestión (ECN), el control de congestión y la negociación de características. La IETF publicó el DCCP como RFC  4340, un estándar propuesto , en marzo de 2006. El RFC  4336 proporciona una introducción.

DCCP proporciona una forma de acceder a mecanismos de control de congestión sin tener que implementarlos en la capa de aplicación . Permite una semántica basada en flujo como en el Protocolo de control de transmisión (TCP), pero no proporciona una entrega en orden confiable. La entrega secuenciada dentro de múltiples flujos como en el Protocolo de transmisión de control de flujo (SCTP) no está disponible en DCCP. Una conexión DCCP contiene tráfico de reconocimiento , así como tráfico de datos. Los reconocimientos informan al remitente si sus paquetes han llegado y si fueron marcados por Notificación explícita de congestión (ECN). Los reconocimientos se transmiten de manera tan confiable como lo requiera el mecanismo de control de congestión en uso, posiblemente de manera completamente confiable.

DCCP tiene la opción de utilizar números de secuencia muy largos (48 bits) que corresponden a un identificador de paquete, en lugar de un identificador de byte como en TCP. La gran longitud de los números de secuencia tiene como objetivo proteger contra "algunos ataques ciegos, como la inyección de reinicios DCCP en la conexión". ^[1]

El protocolo DCCP es útil para aplicaciones con restricciones de tiempo en la entrega de datos. Dichas aplicaciones incluyen transmisión de medios , juegos en línea multijugador y telefonía por Internet . En dichas aplicaciones, los mensajes antiguos se vuelven inútiles rápidamente, por lo que se prefiere obtener mensajes nuevos en lugar de reenviar los mensajes perdidos. A partir de 2017, ^[update]dichas aplicaciones a menudo se han conformado con TCP o han utilizado el Protocolo de datagramas de usuario (UDP) e implementado sus propios mecanismos de control de congestión, o no tienen ningún control de congestión en absoluto. Si bien es útil para estas aplicaciones, el protocolo DCCP también puede servir como un mecanismo general de control de congestión para aplicaciones basadas en UDP, al agregar, según sea necesario, mecanismos para una entrega confiable o en orden sobre UDP/DCCP. En este contexto, el protocolo DCCP permite el uso de mecanismos de control de congestión diferentes, pero generalmente compatibles con TCP .

Los siguientes sistemas operativos implementan DCCP:

• FreeBSD , versión 5.1 ^[2] como parche
• Linux desde la versión 2.6.14, ^[3] pero marcado como obsoleto desde la versión 6.4 debido a la falta de mantenimiento y programado para su eliminación en 2025. ^[4]

Biblioteca de espacio de usuario:

• La implementación de DCCP-TP está optimizada para la portabilidad, pero no ha tenido cambios desde junio de 2008. ^[5]
• El propósito de esta implementación de GoDCCP es proporcionar un marco estandarizado, portátil y compatible con NAT para comunicaciones punto a punto con control de congestión flexible, según la aplicación.

El encabezado genérico DCCP adopta distintas formas según el valor de X, el bit de números de secuencia extendidos. Si X es uno, el campo de número de secuencia tiene una longitud de 48 bits y el encabezado genérico ocupa 16 bytes, como se muestra a continuación.

Si X es cero, solo se transmiten los 24 bits bajos del número de secuencia y el encabezado genérico tiene una longitud de 12 bytes.

Puerto de origen: 16 bits

Identifica el puerto de envío.

Puerto de destino: 16 bits

Identifica el puerto de recepción.

Desplazamiento de datos: 8 bits

El desplazamiento desde el inicio del encabezado DCCP del paquete hasta el inicio de su área de datos de aplicación, en palabras de 32 bits.

CCVal: 4 bits

Utilizado por el CCID del HC-Sender.

Cobertura de suma de comprobación  (CsCov): 4 bits

La cobertura de suma de comprobación determina las partes del paquete que están cubiertas por el campo Suma de comprobación.

Suma de comprobación: 16 bits

La suma de comprobación de Internet del encabezado DCCP del paquete (incluidas las opciones), un pseudoencabezado de capa de red y, según la cobertura de la suma de comprobación, todos, algunos o ninguno de los datos de la aplicación.

Reservado  (Res): 3 bits; Res == 0

Los remitentes DEBEN establecer este campo en todos los ceros en los paquetes generados y los receptores DEBEN ignorar su valor.

Tipo: 4 bits

El campo Tipo especifica el tipo de paquete.

Números de secuencia extendidos  (X): 1 bit

Establezca en uno para indicar el uso de un encabezado genérico extendido con números de secuencia y reconocimiento de 48 bits.

Número de secuencia: 48 o 24 bits

Identifica el paquete de forma única en la secuencia de todos los paquetes que la fuente envió en esta conexión.

De manera similar a la extensión del protocolo TCP mediante la capacidad de trayectos múltiples ( MPTCP ), también para DCCP la característica de trayectos múltiples se está debatiendo en el IETF ^[6], que se denomina MP-DCCP. Las primeras implementaciones ya se han desarrollado, probado y presentado en un enfoque colaborativo entre operadores y el mundo académico ^[7] y están disponibles como una solución de código abierto.

• Protocolo de transmisión de control de flujo (SCTP)
• Capa de transporte § Comparación de protocolos de capa de transporte

• Carta del Protocolo de control de congestión de datagramas (dccp) de la IETF

• RFC 4340 — Protocolo de control de congestión de datagramas
• RFC 5595 — Códigos de servicio del Protocolo de control de congestión de datagramas (DCCP)
• RFC 5596: Técnica de apertura simultánea de DCCP para facilitar la travesía de NAT/Middlebox
• RFC 5762 — RTP y el DCCP
• RFC 5238 — Seguridad de la capa de transporte de datagramas (DTLS) sobre DCCP
• RFC 5634: Guía de inicio rápido para DCCP
• RFC 6773: Protocolo de control de congestión de datagramas Encapsulación UDP para travesía NAT

• RFC 4341 — Perfil para el control de congestión DCCP ID 2: Control de congestión similar a TCP
• RFC 4342: Perfil para el control de congestión DCCP ID 3: Control de velocidad compatible con TCP (TFRC)
• RFC 5622: Perfil para el control de congestión DCCP ID 4: Control de velocidad compatible con TCP para paquetes pequeños (TFRC-SP)

• RFC 4336 — Planteamiento del problema del protocolo de control de congestión de datagramas (DCCP)
• Página del DCCP de uno de los autores del DCCP
• Compatibilidad con DCCP en Linux
• Protocolo de control de congestión de datagramas (DCCP)