ELO 323: Redes de Computadores II

Proyecto Individual : Datagram Congestion Control Protocol [RFC:4340]


Contacto: Constanza Valdés - constanza DOT valdes AT alumnos DOT usm DOT cl
                             

Descripción del Problema
  Los requerimientos como telefonía en internet, flujos de vídeo o audio, videoconferencia y juegos online masivos no son cubiertos completamente por el protocolo ampliamente usado UDP. Éste es el elegido debido a que la confiabilidad no es prioridad frente a la interactividad en tiempo real y extrema sensibilidad al retardo presente. Para resolverlo se propone un nuevo protocolo en la capa de transporte que sea capaz de negociar un control de congestión pero no ofrece confiabilidad, es decir está basado en envío de datagramas al estilo UDP.

Características relevantes de DCCP
    DCCP es un protocolo de capa de transporte no confiable, con flujo bidireccional. El tamaño de bits de su acknowledgment es variable y esto permite reducción de overhead.
Tiene diez tipos de paquetes los cuales permiten generar una "half-connection" capaz de sincronizarse y realizar un "reset". A continuación su encabezado:

header_tccp
Extraído de "Designing DCCP: Congestion Control Without Reliability",  By Eddie Kohler, Mark Handley and Sally Floyd, 2006.

Los tipos de paquetes se presentan a continuación:
DCCP-Request
DCCP-Response
DCCP-Data
DCCP-Ack
DCCP-DataAck
DCCP-CloseReq
DCCP-Close
DCCP-Reset
DCCP-Sync
DCCP-SyncAck
Control de congestión DCCP

El protocolo permite la negociación del tipo de control de congestión que se mantendrá durante la conexión, de los cuales existen:
  1. CCID 2 TCP-Like:
    Similares variables a las de TCP como ventana de congestión, partida lenta, otros.
    Los transmisores mantienen una ventana de congestión y envían paquetes hasta completarla.
    Los paquetes son acusados por sus receptores.
    Paquetes descartados y ECN indican congestión. La respuesta es disminuir la ventana a la mitad.
  2. CCID 3 TFRC: 
    Se envía tasa en uso (en vez de ventana de congestión).
    Receptor envía “feedback” (por RTT).
    Transmisor usa el “feedback” para determinar la tasa de envío.
    Si el feedback no es recibido por muchos RTT, entonces la tasa de envío es disminuido a la mitad.
Para conocer todas las especificaciones del protocolo revisar: http://www.read.cs.ucla.edu/dccp/rfc4340.txt
Para revisar el desempeño frente a TCP y UDP revisar: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5267215&contentType=Conference+Publications&queryText%3Ddccp

 
Demostración
  Para realizar un streaming unicast en linux a través del programa VLC (http://www.videolan.org/vlc/) introducir el siguiente comando en el lado del servidor:

vlc -vvv "Directorio del video" --sout '#rtp{dst="IP Destino",port="Puerto",mux=ts,proto=dccp}'

Y para recibir en el lado del servidor:

vlc -vvv dccp://"IP Origen":"Puerto"

Además se desarrolla un proyecto en C++ con socket DCCP, donde un servidor puede recibir hasta tres clientes y escribir a un archivo lo que envíen. Cuando el cliente envíe la palabra "fin" se cerrará la conexión. El servidor al desconectarse todos los clientes también se cierra. Comentado dentro del código está la opción para probarlo con socket TCP.

Código Fuente:    dccp.zip