Final Exam - Part 1

DCCP

Today, it is common practice for an application such as VOIP or streaming video to utlize UDP as a transport protocol.  The preference for UDP is that it is unreliable and transmits packets without regard as to whether they reach their destination.  With these types of applications, it is less important that all packets arrive than it is that most packets arrive without delay.  The concern with this approach is that, with the growing popularity of these types of applications, and the fact that UDP does not, natively, implement congestion control, the internet could suffer.  Because UDP sends out packets without regard to their receipt, it is possible that they could be sending packets to an unresponsive machine, or sending packets somewhere they will be dropped.  This wastes bandwidth because packets are being sent where they will be lost or dropped.  If some form of congestion control where implemented, this would be prevented because the sender would be aware if the reciever is actually receiving the packets.  TCP implements congestion control, but it is not suitable for applications that need packets delivered on time.  

Datagram Congestion Control Protocol (DCCP) was developed as a solution to this problem.  It seeks to provide unreliable transport, but also provide congestion control.  Minimally, DCCP is supposed to provide UDP's demultiplexing and checksum functionality, congestion control in context of flow of packets, sequence number to be able to discuss packet arrival and loss, a feedback channel to convey congestion information back to sender, and support of ECN (Kohler, Handley, Floyd).  To simplify, DCCP is almost a hybrid protocol in that it combines features of UDP and TCP.  

There were a number of areas that had to be addressed in the development of DCCP.  One problem that had to be addressed was what the developers termed "reliable acknowledgements".  The desire was to implement something similar to the acknowledgements used by TCP.  However, the method used by TCP would not work for DCCP.  When using TCP, the machines send ACK messages to each other in order to know if they need to retransmit a packet. In unreliable delivery there is no need to retransmit packets, so these ACK messages would be useless. Also, some report mechanisms require that the receiver send a report on the exact packets received.  Unchecked, this combination can quickly build up.  The theoretical solution to this is that acknowledgements must be partially reliable, meaning that as the client is constantly sending back acknowledgements, the sender must send an ACK of its own now and then.  This allows the sender to throw away the built up acknowledgement state that it sends in the ACK.  The method proposed by the developers to acheive this patial reliability is by including acknowledgements in the sequence number.  DCCP sequence numbers increase on every packet sent, including pure ACKs.  This allows the it to be known how many packets were dropped.


References
"Designing DCCP: Congestion Control Without Reliability", Kohler, Eddie; Handley, Mark; Floyd, Sally.