Designing DCCP: Congestion Control Without Reliability

Motivation: DCCP is a congestion-controlled unreliable transport
protocol designed to provide better timeliness at the cost of
reliability. To minimize overhead, DCCP implements only minimal
functionality in the core protocol.

Key Points:

1) DCCP provides an unreliable flow of datagrams with acknowledgements.
in DCCP, every packet (including pure ACKs) occupies sequence space and
uses a new sequence number. However, cumulative ACKs don't make sense in
an unreliable protocol. Thus, DCCP ackno thus reports he last packet
received rather than the earliest not received.

2) DCCP is packet stream protocol and sequence numbers refer to packets
(not bytes). There is a generic mechanism by which the endpoints can
agree on the values of features or properties of the connection.

3) Acks are defined a little differently in DCCP where an application
might request a drop-from-front receive buffer. A packets is ACKed only
when its options have been processed. In DCCP, an ACK never guarantees
that a packet's data will be delivered to the application. Different ACK
formats are also provided to cater to the needs of different
connections. The Data Dropped option indicates that some packets
reported as received actually had their data dropped before it reached
the application.

4) An important concept is half-connection which consists of the data
packets sent in one direction plus the corresponding ACKs sent in the
other direction. Each half-connection is managed by a congestion control
mechanism specified by CCIDs. A half-connection receiver sends the Slow
Receiver option to its sender to indicate that its having trouble
keeping up with the sender's data.

5) The protocol seems weak in terms of robustness against attacks. An
on-path active attacker (compromised router) can hijack a connection
with or without mobility. Although, it seems reasonable that it would be
difficult to provide a secure protocol with extremely low latency as is
desired by DCCP. Additionally, attackers need to guess valid sequence
numbers to be able to hijack a connection.

6) DCCP provides primitive support for multihoming and mobility to solve
only the basic problems. DCCP has no support for simultaneous moves or
more complex mobility semantics. In such scenarios, Mobile IP may still
be the likely solution.

7) A major problem with deployment would be issues like making NATs and
firewalls understanding the protocol.
 
DCCP definitely seems an interesting idea for providing applications a
middle ground between reliable TCP and the unreliable UDP.
Received on Mon Oct 09 2006 - 20:23:53 EDT