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 . DCCP implementa el establecimiento y la finalización confiables de conexiones, la Notificación Explícita de Congestión (ECN), el control de congestión y la negociación de características. El IETF publicó 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 los mecanismos de control de congestión sin tener que implementarlos en la capa de aplicación . Permite una semántica basada en flujos, 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 acuse de recibo , así como tráfico de datos. Los acuses de recibo informan al remitente si sus paquetes han llegado y si fueron marcados con Notificación Explícita de Congestión (ECN). Los acuses de recibo se transmiten con la confiabilidad que requiera el mecanismo de control de congestión en uso, posiblemente con total confiabilidad.

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

DCCP es útil para aplicaciones con restricciones de tiempo en la entrega de datos. Dichas aplicaciones incluyen transmisión de medios , juegos multijugador en línea y telefonía por Internet . En estas aplicaciones, los mensajes antiguos se vuelven rápidamente inútiles, por lo que se prefiere recibir mensajes nuevos a reenviar mensajes perdidos. A partir de 2017Estas aplicaciones suelen optar por TCP o utilizar el Protocolo de Datagramas de Usuario (UDP) e implementar sus propios mecanismos de control de congestión, o bien carecen por completo de control de congestión. Si bien DCCP resulta útil para estas aplicaciones, también puede funcionar como un mecanismo general de control de congestión para aplicaciones basadas en UDP, añadiendo, según sea necesario, mecanismos para la entrega fiable o en orden sobre UDP/DCCP. En este contexto, 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 ]} Linux 6.16 elimina DCCP. ^{[ 5 ]}
  • DCCP fue eliminado de Linux 6.16. ^{[ 6 ] [ 7 ]}

Biblioteca de espacio de usuario:

• DCCP-TP Archivado el 23/07/2008 en la Wayback Machine. La implementación está optimizada para la portabilidad, pero no ha sufrido cambios desde junio de 2008. ^{[ 8 ]}
• El objetivo de esta implementación de GoDCCP es proporcionar un marco estandarizado, portátil y compatible con NAT para comunicaciones punto a punto con un control de congestión flexible, según la aplicación.

El encabezado genérico DCCP adopta diferentes formas dependiendo del valor de X, el bit de Números de Secuencia Extendidos. Si X es uno, el campo 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 menos significativos 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 receptor.

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 remitente HC.

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

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

Suma de verificació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 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

Establecer en uno para indicar el uso de una cabecera genérica extendida con números de secuencia y acuse de recibo de 48 bits.

Número de secuencia : 48 o 24 bits

Identifica el paquete de forma única dentro de la secuencia de todos los paquetes que la fuente envió a través de esta conexión.

De forma similar a la extensión del protocolo TCP que añade capacidad de rutas múltiples ( MPTCP ), se está debatiendo una extensión de rutas múltiples de DCCP en el IETF ^{[ 9 ]} , denominada MP-DCCP . Ya se han desarrollado, probado y presentado las primeras implementaciones mediante un enfoque colaborativo entre operadores y el ámbito académico ^{[ 10 ]} , y están disponibles como solución de código abierto.

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

• Estatuto del Protocolo de Control de Congestión de Datagramas (DCCP) de la IETF