Review: DCCP resubmission (properly formatted)

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:03:56 EDT