DCCP tiene dos funciones básicas, la primera es establecer, mantener y terminar conexiones no confiables; la otra es utilizar mecanismos de control de congestión para conexiones no confiables. Las principales características de DCCP se listan a continuación:

• Transmisión de datos no confiables, no se retransmiten paquetes perdidos.
• Establecimiento, y término de conexión confiable.
• Opciones de paquetes adecuada, por ejemplo registro del estado de recpción del cliente, o registros del porqué un paquete se perdió.
• Elección dinámica del control de congestión, elige en forma apropiada entre dos mecanismos: Congestion Control ID 2 (CCID2) (como TCP) y CCID3 correspondiente a TCP-Friendly Rate Control (TFRC).
• Prevención ante ataque por inundación de SYN.
  
  
• Formato de Paquetes

Figura 1: (a) Formato de Paquete DCCP (b) Encabezado Genérico DCCP ( c) Subencabezado de Acknowledgment number.

La figura 1a muestra el formato de un paquete DCCP. La primera parte es un encabezado genérico que comparte la misma estructura con todos los paquetes. Le sigue un campo de largo fijo de acuerdo al tipo específico de paquete y luego por una lista de largo variable de opciones. La figura 1b muestra el formato de un encabezado genérico DCCP. Corrimiento de datos, representa la ubicación de los datos medido desde el inicio del encabezado al inicio de los datos. CCVal indica el mecanismo de control de congestión usado (CCID2 o CCID3). CsCov (checksum coverage) determina qué rango cubre el checksum; cuando CsCov=0, el receptor calcula el checksum para todo el contenido del paquete mientras que cuando CsCov=1 a 15 el checksum cubre solo el contenido de los primeros (CsCov -1)*4 bytes de datos además del encabezado y las opciones. Los campos anteriores CCval y CsCov no aparecen en protocolos como TCP o UDP. CCval permite a la aplicación elegir en forma dinámica un mecanismo de control de congestión adecuado de acuerdo a sus requerimientos y las condiciones de la red; CsCov por su parte mejora el rendimiento en enlaces propensos a errores para aplicaciones que pueden soportar paquetes corruptos. Tipo, indica el tipo de paquete. Actualmente DCCP ha definido 10 tipos de paquetes: DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close, DCCP-Reset, DCCP-Sync y DCCP-SyncAck. DCCP tiene dos tipos de largos de paquetes, de acuerdo al campo X en el encabezado. Cuando X=1 el largo del número de secuencia de paquete (seqno) es 48 bits (16 altos más 32 bits bajos) y el encabezado el paquete ocupa 16 bytes. Cuando X=0, el largo del número de secuencia de paquete is 24 bits ( 8 bits reservados más 16 bits altos), y el encabezado del paquete ocupa 12 bytes. En consecuencia, el overhead del encabezado del paquete se encuentra entre UDP (8 bytes) y TCP (20 bytes). El número de secuencia es en unidades de paquetes y se incrementa en uno cuando se envía un paquete, incluso si se envía un paquete que no es de datos como DCCP-Ack. Paquetes que no sean DCCP-Data y DCCP-Request aúaen un número de acknowledgment (4 u 8 bytes) localizado en un campo adicional (figura 1c).

DCCP es un protocolo orientado a la conexión y proorciona una conexión bidireccional, ambos lados pueden enviar tanto datos como aknowledgments. Ya que muchas aplicaciones multimedia usan flujos de datos asimétricos, DCCP también provee conexión unidireccional. Una transmisión unidireccional significa que se transmite paquete de datos y el receptor responde con los acknowledgments correspondiente. Cuando no hay datos que enviar el recptor no genera un acknowledgment traduciendose en una reducción del overhead. Se puede pensar una conexión bidireccional como una combinación de dos conexiones unidireccionales. Una conexión DCCP consiste en tres fases: establecimiento de la conexión, transferencia de datos y término de la conexión. DCCP ha definido 9 estados que indicanel proceso de estas fases: CLOSED, LISTEN, REQUEST, RESPOND, OPEN, CLOSEREQ, CLOSING y TIMEWAIT.

• Establecimiento de la Conexión: DCCP usa un saludo de manos de tres vías (three way handshake) igual que TCP. Este proceso se muesra en la figura 2. El servidor inicialmente está en estado LISTEN. Cuando recive un un paquete DCCP-Request desde un cliente para establecer una conexión, respone con un paquete DCCP-Response e ingresa al estado RESPOND. El cliente envía un paquete DCCP-Ack al servidor para acusar recibo del paquete DCCP-Response. Cuando el servidor recibe el paquete DCCP-Ack, entral al estado OPEN considera el establecimiento de la conexión completado. Simultaneamente, el cliente cambia su estado de REQUEST a PARTOPEN y finalmete a OPEN. Después que los dos lados establecen la conexión comienzan a intercambiar datos. El cliente no puede entrar al estado OPEN en forma inmediata después de recibir el paquete DCCP-Response. Si un paquete DCCP-Ack/DCCP-DataAck se pierde, el servidor no entra en el estado open y por lo tanto no puede enviar datos. Si el transmisor ya estaba en el estado OPEN esto llevaría a un punto muerto. Por lo tanto, el cliente ingresa al estado PARTOPEN después de enviar un paquete DCCP-Ack. Si el cliente se mantiene en este estado después de un período fijo de tiempo entonces enviará repetidamente paquetes DCCP-Ack/DCCP-DataAck hasta el segmento de vida máximo (MSL) expire cuatro veces (el establecimiento de la conexión falla) o hasta que el cliente recibe un paquete DCPP-Data/DCCP-Ack/DCCP-DataAck y entra a al estado OPEN. MSL es el maximo tiempo que un paquete puede sobrevivir en la red.

  
  
  
  

  Figura 2: Establecimiento de conexión DCCP (three way handshake)

• Cuando ambos lados han establecido la conexión, usualmente negocian características de la conexión ( esto puede ocurrir en cualquier momento pero generalmente ocurre durante el establecimiento de la conexión). Un DCCP-Rquest lleva una opción negociación de característica para informar valores de características que el cliente quiere usar, mientras un DCCP-Response lleva opciones de negociacion de características que el servidor quiere ocupar. Durante la negociación de características, el servidor y el cliente usan las opciones Change L, Change R, Confirm L y Confirm R para llegar a un acuerdo en las opciones de características. La opción Change significa el comienzo de la negociación y Confirm significa que la negociación está completa. Cada opción Change contiene una lista de valores ordenados por preferencia, donde el más preferido aparece primero. Cada opción Confirm contiene el valor confirmado, seguido de una lista de preferencias. Por ejemplo, un cliente envía la opción Change R (CCID, 2 3) al servidor, donde 2 3 representan la preferencia del cliente por CCID2 sobre CCID3. El servidor responde con la opción Confirm L (CCID,3, 3 2) que significa que el servidor eligió CCID3 cy 3 2 es la lista de preferencias del servidor. CCID3 es control de congestión que los dos lados acordaron usar. DCCP utoloza una opción init cookie para evitar un ataque por inundación de SYN al servidor antes de que el proceso de “three way handshake” termine. Cuando el servidor recibe un paquete DCCP-Request no asigna recursos para esta petición sino que incrusta la opción init cookie en el paquete DCCP-Response y lo envía al cliente. El cliente entonces debe responder a la opción ini cookie. El servidor debería diseúar su init cookie para saber si es que la cookie retornada es falsificada. El contenido de la cookie debería consistir en el número inicial de secuencia, el número del acknowledgment, el número del puerto u otras, el contenido es encriptado con una clave privada de manera que el cliente no pueda descifrarla. Cuando el servidor recibe otra init cookie usa la clave para descifrarla y verificar si la información corresponde con el conenido original antes de establecer la conexión.

• Tranferencia de Datos: El intercambio de paquetes de datos entre el cliente y el servidor no es confiable pero tiene control de congestiòn. Cada paquete DCCP tiene un número de secuencia, y los números de secuencia de los paquetes desde el cliente son independientes de los números de secuencia de los paquetes desde el servidor, por lo tanto cada lado puede facilmente rastrear los paquetes recibidos o enviados. Dado que DCCP no ofrece un mecanismo de retransmisión éste no tiene un número acumulativo de acknowledgment, así el número de acknowledgment informa el último paquete recibido (distinto a TCP, el que informa el nùmero de secuencia màs pequeúo de los paquetes no recibidos). La figura 3 muestra al clienter ennviando packet (seqno=1) y packet (seqno=2) y el servidor responde con packet (seqno=5 y ackno=2), luego el cliente envía packet(seqno=3 y ackno=5). Durante el proceso de tranferencia, el cliente o el servidor pueden usar paquetes DCCP-Sync y DCCP-SyncAck para sincronizarse. Por ejemplo, en la figura 3, el cliente envía packets(seqno=10~101) y sólo packet(seqno=10) y packet(seqno=101) llegan al servidor, mientras que los otros se pierden. El servidor recibe packet (seqno=101), pero éste número no ésta dentro del rango esperado. Para sincronizar el número de secuencia con el cliente, el servidor envía un paquete DCCP-Sync y acusa recibo del paquete con ackno=101. Cuando el cliente recibe el paquete DCCP-Sync, éste responde con un paquete DCCP-SyncAck, una vez recibido éste paquete el servidor cambia el rango esperado de seqno para sincronizar ambos lados.

  

  Figura 3: Transferencia de datos en DCCP

  En contraste con TCP el acuse de recibo de DCCP tiene dos caractŕisticas distintivas: están limitadas a control de congestión y el transmisor debe informar acuse de recibo al receptor de manera oportuna. Cada acuse de recibo tiene una opción vector ack que el receptor usa para informar la recpción al transmisor. El vector comprende una serie de bloques de 8 bits que incluyen state (2 bits) y run lenght (6 bits). El vector tiene tres estados definidos: received (0), recieved pero con una marca de notificación explícita de congestión (ECN) (1) y aún no recibido (3). Run lenght representa cuántos paquetes consecutivos están en el estado given. Mientras el receptor obtiene más paquetes, informa más estados received al transmisor lo que causa que el tamúo del vector se incremente gradualmente. Asi que el transmisor debe ocasionalmente responder al receptor a traves de acks de acks, notificando la receptor sobre qué acuses de recibo el transmisor ha recibido. Tan pronto el receptor recibe los acks de acks, puede olvidar las condiciones de paquetes recibidos que el transmisor ha reconocido reduciendo así el tamúo del vector de acks. DCCP tiene otra importante característica , DATA DROP, que permite al transmisor distinguir la causa que ocasionó cada pérdida de paquete. La opciòn data drop comprende una serie de bloques de 8 bits. El bit más significativo representa si el receptor a transferido satisfactoriamente los paquetes recibidos a la capa de aplicación. Despúes siguen 3 bits que indican la causa de la pérdidaque inclyen limitaciones del protocolo (0), la aplicación no responde (1), buffer del receptor (2), corrompido (3), y entrega corrompida (7). Los 4 bits restantes son el run lenght.

• Término de la conexión: La figura 4a muestra el proceso con el cual DCCP termina la conexión. Cuando el cliente intenta terminar la conexión envía un paquete DCCP-Close. Una vez recibido éste paquete, el servidor envía un paquete DCCP-Reset para finalizar el proceso de término de la conexión. Cuando el cliente recibe el paquete DCCP-Reset termina la conexión luego de esperar 2 MSL. El proceso por el cualel servidor intenta terminar la conexión es simila a lo descrito previamente: el servidor envía un paqute DCCP-Close, luego el cliente envía un paquete DCCP-Reset y finalmente el servidor espera en el estado TIMEWAIT durante 2 MSL. En general, DCCP alcanza el término de la conexión con un paquete DCCP-Close y uno DCCP-Reset independiente de quién inicializa el proceso. En todo caso, el servidor puede permitir al cliente permanecer en el estado TIMEWAIT. En este caso, el servido envía primero un paquete DCCP-CloseReq al cliente el resto es igual a lo descrito anteriormente.

  

  Figura 4: Término de la conexión.

• Control de Congestión:Las aplicaciones pueden escoger el control de congestión más apropiado de acuerdo a sus requerimientos. El servidor y el cliente pueden negociar el mecanismo de control de congestión que quieren usar mediante caracteristicas de opciones de negociación. DCCP ha definido dos mecanismos de control e congestión, CCID2 y CCID3. CCID2 es un control de congestión como el de TCP que es apropiado para flujo de paquetes en ráfagas mientras que CCID3 ofrece control de congestión TFRC el que es apropiado para flujos de paqutes mas suaves.
  
  CCID 2: CCID 2 utiliza el control de congestión AIMD (aditive increase/multiplicative decrease) donde el transmisor adopta una ventana de congestión para controlar la tasa de transmisión. El transmisor ajusta el valor de la ventana de acuerdo a la información proveniente de los acuse de recibo. CCID usa tres variables importantes variables entera: cwnd (congestion window), la máxima cantidad permitida de paquetes pendientes, ssthresh (slw-star threshold) un umbral de la ventana de congestión que separa la partida lenta de evitamiento de congestión y pipe el número estimado de paquetes pendientes.
  El control de congestión tambien recicla acuses de recibo para prevenir que éstos congestiones la red.
  El transmisor utiliza la característica ack ratio para ajustar dinámicamente la tasa de envío de acuses de recibo. La tasa de envío de acuses de recibo es 2 por defecto, lo que quiere decir que el receptor responde a un acuse de recibo luego de recibir dos paquetes. El control de congestión para acuses de recibo es similar al de datos. Cuando el transmisor detecta un acuse de recibo perdido dobla la tasa de ack por lo tanto reduce a la mitad la tasa de respuesta de acuses de recibo. Cuando el transmisor recibe acuses de recibo.
  
  CCID 3: CCID 3 utiliza el control de congestión TFRC. El transmisor utiliza la tasa de perdidas que el receptor mide, calucla la tasa de transmisión T mediante la siguiente fòrmula y ajusta su tasa de transmisión:

  
  
  donde Tes la tasa de transmisión, S es el tamaúo del paquete, RTT es el round trip time, trto es el tiempo de retransmisión y p es la tasa de perdidas. En la fase inicial, partida lenta, la tasa de transmisión se dobla por cada RTT hasta que el receptor informa una périda de paquete o una marca ECN, luego el transmisor deja la fase 1 y usa la ecuación anterior para calcular la tase de transmisión permitida para el siguiente período. CCID 3 espera obtenr un rendimiento similar a TCP en un ambiente en que los dos coexistan y además ontener una tasa de transmisión pareja.
  
  ReferenciasDCCP:
  Transport Protocol with Congestion Control and Unreliability Yuan-Cheng Lai • National Taiwan University of Science and Technology
  Performance Analysis of Datagram Congestion Control Protocol (DCCP) Iffat Sharmin Chowdhury, Jutheka Lahiry, Syed Faisal Hasan
  WWW.LINUX-MAGAZINE.EDesarrollo de aplicaciones multimedia con DCCPS POR LEANDRO MELO DE SALES