(no subject)

From: Jin Jin <jinjin_at_eecg.toronto.edu>
Date: Sat, 7 Oct 2006 17:03:47 -0400

This paper proposes a congestion-controlled unreliable transport
protocol. It adds to a UDP-like foundation the minimum mechanisms
necessary to support congestion control. The resulting protocol sheds
light on how congestion control interacts with unreliable transport,
how modern network constrains impact protocol design, and how TCP's
reliable bytestream semantics intertwine with its other mechanisms,
including congestion control.

Lacking any congestion avoidance and control mechanisms, network-
based mechanisms are required to minimize potential congestion
collapse effects of uncontrolled, high rate UDP traffic loads. In
other words, since UDP senders cannot detect congestion, network-
based elements such as routers using packet queueing and dropping
techniques with often be the only tool available to slow down
excessive UDP traffic. DCCP is being designed as a partial solution
to this potential problem by adding end host TCP-friendly congestion
control behavior to high-rate UDP streams such as streaming media.

Focused requirements of the applications using UDP like Internet
telephony, streaming media, interactive games, redesigning the UDP
protocol is needed. The goals for DCCP include a) Minimalism. A
protocol minimal in both functionality and mechanism is preferred. b)
Robustness. A modern protocol must behave robustly in the presence of
attackers as well as network address translators, firewalls, and
other middleboxes. c) A framework for modern congestion control. DCCP
should support many applications. d) Self-sufficiency. DCCP should
provide applications with an API as simple as that UDP. e) Support
timing-reliability tradeoffs.

DCCP is a unicast, connection-oriented protocol with bidirectional
data flow. It is an unreliable protocol with the idea springing from
TCP. DCCP's core connection management features all depend on the
most fundamental tool available, namely sequence numbers. Unlike TCP,
in DCCP, every packet, including pure acknowledgements, occupies
sequence space and uses a new sequence number. The semantics of
acknowledgement are very different for an unreliable protocol than
for TCP, as there is no succinct equivalent to TCP's cumulative
ackno. DCCP acknowledges the most recently received packet. Providing
robustness via sequence number validity checks is harder for an
unreliable protocol. DCCP thus provides an explicit synchronization
mechanism. This has some advantages even over TCP's design. To solve
the sequence number length problem, the simplest and best solution
was simply to lengthen sequence numbers to 48 bits. However, forcing
the resulting overhead on all packets was considered unacceptable. So
endpoints should be able to choose between short and long sequence
number. Although DCCP sequence numbers are 48 bits long, some packet
types may leave off the upper 24 bits.

TCP's congestion control is so tightly coupled to its reliable
semantics that few TCP mechanisms are directly applicable without
substantial change. However, it's possible to design a relatively
simple protocol that robustly manages congestion-controlled
connections without reliability. Explicit synchronization and new
acknowledgement formats even have some advantages over their TCP
equivalents. Modular congestion control mechanisms make it possible
to adapt congestion control within a fixed protocol framework as
network and application constrains changes. Robustness against attack
is addressed in a more thorough way.

The paper is well written, with fine and clear presentation.
Obviously, it is a kind of revolutionary work. It makes a great
change of UDP. At first, UDP is connectionless protocol. Now for
solving the problems of lacking congestion avoidance and control
mechanism for UDP applications, authors change the UDP to a
connection-oriented protocol UCCP. It not only provides the
modifications which spring from TCP, but also proposes the whole
mechanism supporting the applications and deployment. This paper is
very solid. Authors provide almost every detail. However, there still
are some weak points.

Authors did not provide any theoretical analysis. All are based on
some description. Especially, why the mechanism is robust, why it
could implement control congestion. Authors should use control theory
to analyze the point. Moreover, there is no experiment or simulation
in the paper which could not convince readers. This paper introduces
a new protocol. So absolutely, simulation and measurement are needed
to demonstrate the conclusion. How the congestion control mechanism
works under certain application like on-line game or VOIP. Another
problem is that authors think the explicit synchronization and new
acknowledgement formats even have some advantages over TCP
equivalents. Is it true? Author did not express it very clearly. And
how to prove that?
Received on Sat Oct 07 2006 - 17:03:57 EDT

This archive was generated by hypermail 2.2.0 : Sun Oct 08 2006 - 15:40:27 EDT