review

The paper discusses the design of the Datagram Congestion Control
Protocol (DCCP) for implementing

congestion control in high-bandwidth UDP applications such as streaming
media and telephony. At

each step it compares their approach to that in TCP. The authors discuss
their 5 goals:
1. Minimalism in both functionality (DCCP should not provide
functionality that can be layered

above it) and mechanism (DCCP's core protocol features should be few in
number but rich in

implcation.
2. Robustness against data injection, connection closure and DoS
attacks, i.e. attacks where the

connection sequence numbers can't be guessed correctly. In order to
provide robustness and

transparency, they introduced explicit connection setup and teardown.
3. Framework for modern congestion control: DCCP should support many
applications and provide a

framework for implementing congestion control, not a single fixed algorithm.
4. Self-sufficiency: DCCP should provide aaplications with a simple API
and no application

intervention should be needed for congetsion management.
5. Support timing-reliability tradeoffs: API for sending DCCp packets
should support some buffering

and DCCP should support applications that want fine-grained control over
buffers and other

tradeoffs between timing and reliability.
The paper described DCCP as a very simple overview of their unicast,
connection-oriented protocol

with bi-directional data flow. Connections start and end with a three
way handshake, datagrams

begin with 16-byte generic datagram headers.
The authors then discuss various design issues and decisions starting
with sequence numbers. Since

DCCP must be able to detect loss without application support, its
headers must include sequence

numbers, which measure datagrams (and not bytes like TCP). Every packet,
including acknowledgements

occupies sequence space and uses a new sequence number. Furthermore,
since cumulative acks are not

used in unreliable protocols where data is never retransmited, DCCP
acknos report the latest packet

received (and not the next expected one). They chose a variable length
sequence number. 48-bit

provides better security bit can be a large overhead for small packets
such as 8-byte codecs, and

hence 24-bit sequence numbers are also allowed, and these can be
extended on the fly. A 48-bit

sequence number also provides ribustness against attack (although 24-bit
does not provide this)
DCCP provides explicit synchorization (consisting of a Syn and SyncAck
packet) when the connection

is interrupted by network failure (which may result in the endpoints
having different sequence

numbers).
Furthermore, since DCCP acknowledgements contain unbounded state
(AckVector can report every packet

received from the beginning of the connection), the sender must
acknowledge that is getting ACKS so

that the receiver can discard the corresponding ack info. Also, an ack
only acknowledges that a

packet has reached the receiver, not that it was delivered to the
application.
The paper then discusses connection management. They talk about
asymmetric connection, where one

side of the connection is sending only acks and no data. DCCP uses
half-connections so that if one

-way becomes silent, acks do not need to be sent back and hence state
does not need to be

maintained for that.
Since there are several per-endpoint properties whose value both
endpoints must agree on

(features), it is necessary to negotiate these at connection set up and
this is done through change

options to open feature negotiation and confirm options sent in response
with the values.
The paper then talks about mobility and multihoming as well as DoS
attacks against servers (which

are reduced by pushing state to the client).
DCCP supports 2 congestion control algorithms:
1. a modified version of TCP which also provides congestion control for
acks.
2. TFRC
Received on Tue Oct 10 2006 - 08:00:46 EDT