Designing DCCP: Congestion Control Without Reliability May 29, 2009

The primary contribution of the paper is the design of the datagram based unreliable congestion control protocol. The protocol performs congestion control to avoid overwhelming the network, but does not guarantee reliability or in order delivery of packets. These features can be layered on top of DCCP and are typically not required for the applications that DCCP targets. The protocol itself is built in a modular fashion and provides a mechanism to support different congestion control algorithms based on the application need.

The detection of reverse path congestion is another nice idea that has not been achieved in TCP. However, I find it hard to understand how exactly that can be used. One potential possibility that I can think of is  that if congestion is detected on the reverse path, then delayed ACKs can be used with larger delay (more packets acknowledge by a single ACK). This avoids overwhelming the network with the use of ACKs.

The idea of using ACKs to indicate the last received packet rather than the lowest sequence number  not yet received (as in TCP) is another cool idea which leverages the fact that DCCP is an unreliable protocol unlike TCP. Also, the notion of ACKs indicating the receipt of particular packets rather than bytes, is inherent to the idea that DCCP is a datagram protocol rather than a byte stream based protocol.

One of the primary concerns with DCCP is that there is not sufficient incentive for a user to start using DCCP. Other users who use UDP would likely be able to get higher bandwidth from the network since they do not back off due to congestion. Applications like video streaming typically already include some form of application level feedback in the reverse direction which indicates the goodput and can hence be used to switch codecs based on the usable bandwidth (coarse granularity). Typically network congestion is a transient condition and switching codecs at that fine granularity when congestion occurs does not lead to perceivable performance difference for users.

Future research could look at how to provide incentives for users to adopt DCCP for datagram based protocols. Determining different congestion control algorithms to use with DCCP is another direction for research.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

As an alternative to UDP, the authors propose DCCP which combines the unreliable nature of UDP’s delivery mechanism with TCP-like congestion control.

1. Applications such as multimedia video and audio currently use UDP, but they implement their own congestion control mechanism at the application layer. The authors point out that this leads to enormous overhead on part of the application programmer, and any bug will potentially affect other flows in the network. Also, multiple implementations will lead to incompatibility and duplication of effort. This is the motivation behind DCCP protocol which like UDP prioritizes timeliness over reliability, but provides TCP-like congestion control for long-lived datagram applications.
2. The authors make a credible case for why certain features were not included in DCCP, for what they consider a minimal DCCP design. This gives confidence in their design process. The minimal design omits flow control, selective reliability, streams and multicast, since all of these (except multicast) can be implemented above DCCP layer, without any changes to DCCP itself.
3. The authors propose two schemes for congestion control. The first one is similar to TCP — as the available bandwidth changes, the sender rate (congestion window) also changes. One significant difference is that acknowledgments in DCCP are also congestion-controlled. The second method is based on TCP-Friendly Rate Control (TFRC). This uses the feedback from the receiver feedback.

My issue with thsi paper is that the authors have conducted little testing of application performance with DCCP. The focus has been mainly on the design decisions, but for a successful protocol, performance is equally if not more important. The obvious advantage of UDP is less connection overhead, which is lost with DCCP employing TCP-like connection management.

Though TCP dominates as of today, the future for a protocol like DCCP is bright because increasingly UDP traffic is steadily on the rise due to videos and internet telephony. The incomplete work on supporting multicast would go a long way in making DCCP more attractive, since live streaming of video on demand is generally thought to be multicast.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

(i) the three most important things the paper says

1. The initial observation that congestion control is necessary in connectionless protocols like UDP (and not as its own layer) is an important one.  The authors argue that having congestion control in any other part of the Internet model (in IP or on its own layer) would require input from each program that implements that protocol; a quite unreasonable demand from application programmers.  The authors also made the observation that having the congestion control in the protocol itself is really the best option for receiving information about packet loss that would be appropriate for a connectionless best-effort protocol.
2. Another important observation that the authors make is that although there should be a “safe” set of parameters (where all mechanisms would work at today’s link speeds), there should also be a method in which to negotiate a smaller header size so that traffic that uses smaller packet sizes (or any other such difference from the “standard” type of communication) won’t suffer by using congestion control in its traffic.
3. A third important observation that the authors make is that a customer of this protocol should have his or her choice of congestion control policies and should not be limited to a mandated policy.  Locking down this decision is often a protocol-killer as that particular design choice (that might not be the “right” one all the time) might not work for all applications.

(ii) the most glaring problem with the paper

I feel that the lack of meaningful simulation/verification is a large problem with this paper.  I found that it was hard to believe that this scheme will work entirely without some sort of empirical evidence of it working (also, it would be useful to see how this will affect different types of connectionless traffic, in terms of performance).  The authors provide some minimal simulation, but simulating this over other internet traffic (TCP, etc.) would be necessary in order to verify the usefulness of this protocol. (Let it be known that this paper was very through, and finding holes in it was a bit difficult for me.)

(iii) the future research directions of the work

One future research direction would be to profile applications using this protocol over UDP (mapping the slowdowns that the application will incur–if any at all, the effect on the latency of the connection, how the protocol coexists with other internet protocols, etc.) .  Another great topic to look at would be if it would be in the best interest of the protocol to look at improving its semantics without referring back to TCP for each comparison.  Some of the design decisions made could be better off without relying on a connection-based protocol for holding the “oracle” of how this connection should behave.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

i)

1. There are many applications that want to send data in real time and the reliability of all packets being delivered is not important. TCP’s reliable delivery can cause delays when there is packetloss and UDP has no mechanism for congestion control. The authors propose DCCP, a UDP like protocol with congestion control, thus allowing it to be a network friendly protocol.

2. The designers were very worried about byte overhead in the headers. One problem with sequence numbers was they needed a large number of bits (48 bits) to avoid the chance of sequence numbers wrapping around. They came up with a clever design to optionally avoid having to send the 48 bit sequence number every time and instead send only a 24 bit sequence number on data packets. The mechanism they use is they keep track of a predicted upper 24 bits and simply extend the 24 bit sequence number on a received packet by using this prediction.

3. They built in a mechanism to detect misbehaving clients. One problem with a protocol like this is that clients can lie to the sender in order to avoid having the sender cut their sending rate, but also a client can’t be expected to receive every packet from the sender. To prevent the client from lying, a single nonce bit is included in every packet and when the client ACKs several packets it must also include the XOR of all the nonce bits for the packets it is acking.

ii) I think the major flaw in this paper was trying to design a new transport layer protocol. New layer 3 and 4 protocols face major hurdles in adoption due to many middle boxes such as NATs having to understand the protocol as well as the end clients. I think it might have been better to design this as a library using UDP packets and pack the DCCP header information that isn’t in the UDP header in the first few bytes of every UDP packet. In this manner the end client applications will understand the protocol, and middleboxes won’t present an obstacle to adoption.

iii) Future research directions should look at the possibility of designing a protocol that uses UDP packets as its underlying mechanism of delivery. This might entail changes to the protocol as well as examining whether the extra overhead is acceptable.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

The Datagram Congestion Control Protocol (DCCP) is a transport layer protocol that values speed over correctness, e.g. streaming media, telephony, etc.

DCCP provides a choice of congestion control schemes. This option is exposed at the application level. The choices are either a selective acknowledgment TCP-style scheme using a congestion window with additional control based on the ratio of data packets to acknowledgments, or a scheme where the sender transmits at a certain rate based on periodic feedback from the receiver.

Retransmissions are not always desirable and are easily added above the transport layer. Thus, everything sent over the transport layer (packets and acknowledgments included) has a unique sequence ID number. Since there are no retransmissions, the acknowledgment ID numbers refer to the latest packet received, leaving the specifics of packets not arriving to other modules within DCCP. Furthermore, for some flows, a 6-byte long sequence number in the header may be a significant amount of overhead, especially when sending e.g. an 8-byte data packet; therefore, DCCP includes an alternate set of headers using a 3-byte long sequence number which is concatenated with 3 upper bytes at the receiver.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

Three Important Things:

• The motivating factor for the design of a new transport protocol is that many internet applications would benefit from unreliable data transfer, and most today use UDP. The UDP protocol lacks congestion control, which represents a significant disadvantage since applications do not want to implement that feature on their own. The solution to this is a new protocol called DCCP. The authors outlined a set of requirements inluding congestion control and robustness. They also outlined a set of omissions including flow control, streams, and multicast. This is an insightful point in protocol design as it illustrates the concept of minimum functionality. The provided features were kept simple and tailored the application needs, and the protocol did not include anything that could be layered on top or make the design overly complex.
• DCCP makes a fundamental change to the TCP sequence number scheme. All packets including acks are assigned numbers from a 48-bit space, as opposed to bytes of data. Acknowledgements are sent to confirm the delivery of the last packet received as opposed to earliest not received. The consequence of this is there is no cumulative tracking of the data stream, and therefore a vector is required to keep connection history. Acknowledgements are themselves acknowledged periodically to help prune the control state. The large number space increases the robustness of the protocol, however there is still a need for an explicit synchronization mechanism in the case of an unexpected sequence number.
• The paper proposes two methods for congestion control. The first is very similar to TCP with the added feature of reverse-path congestion detection. This is achieved by keeping track of the ratio of data packets to acknowledgments. Once the ratio leaves the target zone corrections are made to the sending rate. The second method operates on the principle of receiver feedback. The sender attaches sending rate information once per RTT, and based on this the receiver reports back the loss rate. This method results in smoother changes in the sending rate.

Glaring Problem:

The DCCP designers decided to implement a framework to offer selectable congestion control mechanisms via a flag in the packet header, as opposed to implementing a fixed algorithm. After extensive experience with TCP congestion control experimentation it has been shown that different mechanisms often interfere with each other and could lead to unfair bandwidth allocation among flows. The authors do not address this issue in their discussion, which is significant because the stated goal of the new protocol is the ability to perform effective congestion control for all applications.

Future Work:

Given the lack of performance evaluation for DCCP in the paper, there is much room for simulation and deployment research in order to evaluate the success of the new protocol and the possibility for modifying existing applications to run on a modified kernel with a DCCP stack. The parameters for success should be throughput, fairness, coexistence with TCP etc.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

(i) Three most important things

1. A new protocol is needed to accommodate increasingly popular applications such as Internet telephony, interactive videoconferencing, streaming media, and interactive games. UDP provides unreliable, connectionless data transport, for applications where timeliness is the primary concern but users are forced to implements congestion control themselves. The paper proposes the Datagram Congestion Control Protocol (DCCP) as a new protocol that does not burden the application developer by providing congestion control.

2. Design goals for a new UDP protocol with congestion control would be minimalism, robustness, and framework for modern congestion control. The protocol should be simple in protocol design, implementation, and ability to leverage for applications and should have a reduction in protocol overhead. The protocol needs to be robust to withstand abuse and the protocol should support the congestion control features of TCP, yet still have the capability to evolve over time.

3. The headers of the new UDP protocol with congestion control must include sequence numbers that measure datagrams and ACK numbers should represent the most recent packet received. Sequence numbers should measure datagrams rather than bytes because unreliable applications generally send and receive datagrams rather than portions of a byte stream. DCCP’s ACKs report the most recent packet received and stores additional info in the ACK Vector, a TCP SACK relative that enables DCCP to report the specific packets received.

(ii) Most glaring problem

The most glaring problem would be that unreliable UDP flows are still a small fraction of the total Internet traffic so the case for DCCP just doesn’t seem convincing currently. For now UDP is good enough until unregulated UDP flows become a larger portion of Internet traffic.

(iii) Future Research Directions

Future research directions for this work would be to test DCCP over the Internet and demonstrate the viability of the new protocol in comparison to UDP and TCP and under what kind of networks loads.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

(i) The three most important things the paper says:

1. There is a growing class of applications that are not well suited for the well-established standard transport protocol of today: TCP. This class is comprised of applications that no longer need or even want reliability in there protocol. They are the time-sensitive applications mainly for streaming video, telephony, online gaming etc. These applications reject the notion of retransmitting packets because by the time a retransmission is received the data is no longer pertinent and the bandwidth that could be used to send data for the current time has been wasted. The author presents DCCP as a protocol that can offer the features desired of TCP, like congestion control, without reliability.

2. In normal train of thought this sounds simple. If you view reliability as an extra constraint then you would assume that once this constraint is removed from the protocol the protocol will become simpler and easier to develop. This was however not true in this case. Surprisingly knowing that all packets will eventually arrive allows the acks to be a lot more meaningful since they tell you the entire history of what has been received with just one number. This was just one example of the challenges the authors of DCCP had to overcome.

3. The authors chose to implement variable congestion mechanisms that fit into DCCP. This will allow the applications to choose the one that best fits they’re needs. The first congestion control was very similar to the congestion control implemented by TCP. An improvement was to add an ack ratio so that only some percentage of the packets will be acked thus reducing the congestion added by acknowledgements. The other mechanism implemented by the author was TFRC where the receiver is responsible for acking only periodically and reporting how many losses it has detected. If no ack is received the sending rate must be halved figuring that the link has become very congested.

(ii) The most glaring problem with the paper:

The performance analysis section of this paper was oddly missing. It is hard to know if this protocol has any worth without a comparison on how it performs compared to current methods implemented by these applications using UDP or TCP. Since this crucial information was left out it makes it very hard to know if the goals of the protocol were adequately attained.

(iii) The future research directions of the work:

First, it would be worthwhile to test the current protocols performance before deciding directions in which to pursue researching. The author suggests many possibilities for improvement upon DCCPs current congestion control policies that should be assessed. I was curious if it may prove profitable to only care about the RTT and % of packets being acked instead of focusing much effort on knowing exactly which packets have made it. This makes the sequence numbers much less important.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

UDP does not have any congestion control mechanism originally incorporated. It avoids TCP’s built in end-to-end congestion control mechanism. Till now UDP traffic volume was small relative to the congestion-controlled TCP flows hence network did not collapsed. Recent development of application such as VoIP, on-line games, streaming audio has preference for timeliness over reliability and in-order requirements. This long-lived connection is sometime supported by application level congestion control. DCCP provides an enabling technology for existing and new application to transfer data without destabilizing the Internet. Preference for low overhead, clean and minimal protocol results in design decisions to leave reliability or Forward error correction to be layered on top rather than on transport protocol.

Major problems with UDP are problem of causing network failure due to non-congestion-controlled datagram flow, difficulty of correct implementation, lack of standard for congestion feedback transmission. Reason of using UDP over TCP includes, less start-up delay to avoid three-way handshake before data transfer, they do not wish to hold connection state, trading of reliability against timing due to application nature.

DCCP provides a minimal solution both in functionality and mechanism so it does not provide functionality that can be layered above it by the application. It also achieves the minimal header size (important for applications like VoIP). It is robust against data injection, connection closure and denial of service attack. Its goal is to support timing-reliability trade-off needed by UDP based applications.

DCCP implementation is a unicast connection oriented protocol with bidirectional data flow. Connections start and end with three-way handshakes. It depends upon sequence numbers and detects loss without application support. Every packet occupies sequence space and uss a new sequence numbers. It is different from TCP in a way that ack number corresponds to the latest packet received rather than the earliest not received. This requirement is driven by the application type which might not be interested uin lost packet retransmission.

Synchronizations are supported to resolve the unexpected sequence number/ack number. Unique packets are used to help mutual unsynchronized end points to synchronize. DCCP provides a set of congestion control mechanisms appropriate for applications. These choices are made through Congestion Control Ids(CCIDs). This is negotiated at the connection setup time. CCID 2 is TCP type congestion control and ACK uses Ack Vector option which is similar to TCP SACK. It uses a congestion window. CCID 3 uses sending rate rather than congestion window. If no feedbacks are received for several RTTs then sender reduces the rate by 2. It supports checksum to cover less than entire data which prompts underlying layers to forward corrupt datagrams. Congestion loss can be differentiated from corruption los by reporting corruption separately by the receivers.

Overall DCCP is a simple protocol that manages congestion controlled connections without reliability and caters to the UDP type application which requires reliability-timeliness tradeoffs.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

This paper talks about a new protocol, Datagram Congestion Control Protocol (DCCP) which provides a midway between a protocol like TCP (which has congestion control but doesn’t emphasize timeliness) and UDP (which doesn’t have congestion control but can be used to enforce timeliness). The authors talk about the need of such a protocol in applications like streaming media, internet telephony, videoconferencing, games etc. where timeliness is preferred over reliability. At the same time, these applications do not want to implement congestion control mechanisms themselves which is taken care of in a protocol like TCP but it can introduce arbitrary delay between the byte streams. Therefore, authors propose a new protocol for time sensitive applications where choice of congestion control mechanism is desired, low per-packet overhead is needed and buffering control is required to stop delivering old data. Also, the feature for Explicit Congestion Notification (ECN) which marks the congested packets and a TCP like explicit connection setup and tear down for NAT and firewall support is required. The proposed protocol borrow certain good features of TCP and UDP like port numbers, checksums, sequence numbers(with difficulty), acks (congestion and ECN info), piggybacked acks and three-way handshake to set up and a two-way with wait to tear down the connection. The protocol introduces new concepts like negotiating congestion control (CC) mechanism and parameters on setup and two half way connections. Half way connection is emphasized since traffic is typically asymmetric with different routes implying different congestion issues. Also, it is better than two one-way connections to work better with firewall and NAT and piggybacking ACKs with data. The selection for both half-connections is done in parallel at startup and is generic and extensible. The basic packet structure used is similar to UDP but is smaller and extensible for additional features. The CC mechanisms are ‘plug and play’ whose parameters for both ways are hosen during setup. The two CC mechanisms talked about are TFRC (control equation for changing the sending rate) and TCP-like congestion control with tweaked parameters. The mechanisms are selected using Congestion Control IDs (CCIDs) which names standardized CC mechanisms. In TFRC, the receiver sends feedback to the sender roughly once very round-trip time reporting the loss event rate it is currently observing. The sender uses this rate to determine its sending rate and defaults to TCP-like halving of rate if feedback is not received for several round-trip times. The checksums are partial and covers DCCP header and optionally any number of bytes in the payload. It allows delivery of slightly damaged data and can be useful for error-prone links like wireless.  In DCCP, ACKs are sent for latest received packet rather than earliest not received in TCP. It allows for windows to be resynchronized when out-of-window packet is received. There is also ECN mechanism to prevent misbehaving receiver.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

1. A bare framework in line with the end-to-end argument
DCCP is a congestion control protocol for unreliable connection oriented network. The protocol provides only the bare necessities required for congestion control. All other features have been left for the higher layers to implement. This makes it protocol independent allowing it to support a large number of existing and future protocols. It also makes it application independent which is an important feature considering the type of traffic it was directed at. It is likely that applications for multimedia, VOIP, video streaming etc have advanced mechanisms to implement fine-grained control over the arriving data. Not providing these features in DCCP provides these application the flexibility to implement these feature in a manner most suitable for their needs. This also allows each connection to negotiate its own features depending on the application at hand.

2. Specialized sequencing scheme
DCCP differs from TCP in method it uses for sequence numbering. Every packet in DCCP, regardless of the type of packet it is, gets its own sequence number. Moreover, each packet in DCCP gets a sequence number as compared to a byte-wise sequencing scheme in TCP. Hence the entire exchange maintains a single sequence of numbers for all its packets. This would also imply that each connection would require a larger sequence space.

3. Congestion control specialized for traffic requiring timely delivery over minimize-packet-drop delivery.
DCCP makes several enhancements/changes to TCP congestion control. It provides acknowledgement of acknowledgments. Its sequence number reports the latest packet received as compared to the earliest packet not received since applications here are more concerned with timely delivery as compared to confirmed, every packet delivery. DCCCP also leverages the unidirectional nature of its traffic by maintaining acknowledgment history and order in only a single direction.

Drawbacks
Some of the features provided by them to support real-time traffic adds some over-head over the congestion-control provided for by TCP. A sequence number for every packet implies a larger space for sequence number (48 bits in DCCP as compared to 32 bits used by TCP). The paper does talk about selectively using the upper 24 of the 48 bits. The protocol also requires acknowledgment of acknowledgment packets which would add to the network traffic. The Ack Vector, if used, would lead to even more overhead
In trying to exploit the unidirectional nature of their traffic, a direction goes into a “quiescent” state if there is no traffic in the direction for more than 0.2 second. This could lead to obvious issues if the application involved generates data in bursts.

Future Work
DCCP follows a policy of bare framework. This, while having its advantages, leaves out several hard to implement features to the upper layers. It might be possible to selectively provide these features in DCCP. The paper does mention support for feature negotiation. The more complex features (such as support for multicast) could be added on during feature negotiation. However, there is no end to the additional features that can be provided.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

This paper describes the DCCP protocol, which is designed as an alternative to UDP which will provide the same timeliness prioritization over reliability while adding the congestion control that UDP lacks.

The main points of this paper are as follows:

1. Congestion control should be decoupled from the protocol itself. Different applications have different communications requirements. While some prefer discarding corrupted information, others prefer receiving it. In other cases, some datagrams are more important than others (I-frames vs. B/P-frames in MPEG video), so if some have to be dropped due to buffers, it can be helpful to be able to handle some more carefully than others. DCCP provides flexibility in congestion control by acting as a congestion control framework which different congestion algorithms can be “plugged into.” This has the added benefit of allowing different congestion control for halves of a bidirectional communication, since many of the applications of UDP (and subsequently DCCP) tend to be mostly unidirectional.
2. The main requirement for congestion control is sequence numbers. These allow the protocol to detect loss and respond accordingly. Even though DCCP does not require retransmission, it also does not preclude it, if the application determines that there is sufficient time to make it worthwhile. However, as opposed to TCP, which numbers bytes in a byte stream, UDP and DCCP provide an abstraction in terms of datagrams, not bytes. Therefore, the sequence numbers in DCCP are specified in terms of packets. They also took the opportunity to specify a variable number of bits in the header for sequence numbers. Whereas TCP only specifies 32 bits which are used to specify bytes in the byte stream (which is becoming more and more of a problem with gigabit and higher bandwidths), DCCP can use up to 48 bits to specify a number of packets. This provides resilience against both malicious users (trying to run reset attacks is much harder than it is against TCP) and mistimed packet arrivals. However, they also recognized that not all applications need the overhead of 48-bit sequence numbers, so they created an option to use 24-bit numbers instead. This opens the attack window for reset attacks, but reduces the overhead when it is unlikely that mistimed packets will overlap a window in 24-bit space. This provides the application developer a choice of resilience or overhead.
3. Connection management should provide flexibility in usage models. In order to provide congestion management, DCCP is required to use a connection-based paradigm more similar to TCP. However, since connections over DCCP can often be mostly unidirectional, it is helpful to be able to configure the half-connections separately. DCCP provides this through feature negotiation, wherein both sides of a connection can agree on the policies to be implemented at one or both endpoints. In addition to adding per-direction policies, DCCP provides mobility support by allowing multiple connections to tie into a single session. This is made much easier since DCCP is an unreliable protocol and therefore requires much less synchronization upon the change in an endpoint’s location.

The main weakness in this protocol is that it is not backwards compatible in any useful sense with either TCP or UDP. While it is careful to be TCP-friendly (and indeed, compared to UDP, almost anything is friendlier to TCP), it requires fresh implementations on end-nodes, NATs, etc., which is a distinct barrier to deployment.

It would be interesting to see future research on this protocol using an overlay on a UDP system. Since NATs already support UDP, it might be an effective way to test the congestion control policies without requiring multiple nodes on the path to understand a new protocol. However, it remains to be seen whether it would be as effective as an overlay.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

TCP is the predominate Internet transport protocol. TCP ensures reliable delivery and limits its transfer rate in order to avoid network congestion. UDP follows TCP in popularity. UDP performs unreliable delivery without congestion control. UDP is used when real-time delivery of data is paramount, i.e., VOIP. DCCP, Datagram Congestion Control Protocol, is new protocol that performs unreliable delivery with congestion control.

DCCP has a modular design that allows the implementation of new congestion control algorithms. The application designer specifies which congestion control algorithm is used in each direction of a DCCP session. The initial design includes 2 protocols. A TCP-like algorithm quickly determines the maximum flow rate and quickly adjusts to changes in available capacity. A second protocol option more easily maintains a constant rate.

DCCP has a default API that is similar to UDP. Its default simplicity will facilitate its use as a UDP replacement. The protocol does allow the user to specify a desire for greater timeliness versus reliability. Real time applications e.g., VOIP, games, often have latency bounds on delivery beyond which the data is useless. A DCCP programmer can specify that newer data be presented and old data be deleted from the receive buffer.

One definition of perfection is when there is nothing left to remove. The DCCP designers followed this motto. Flow control, selective retransmission, streams, and multicast were purposefully not included in DCCP. Consideration for security is included. The minimum facilities to meet the problem were implemented. Additional function is left as an exercise for the application programmer.

Current congestion control methods are limited to the various flavors of TCP. New congestion control algorithms are designed to be TCP friendly. DCCP modular approach to congestion control is a boon for congestion control algorithm designers. The coming onslaught of congestion control algorithms may interact unpredictably. It is no longer sufficient to be merely TCP friendly. An objective method of appraising congestion control algorithms is required.

The document points out the state of the art in congestion control is still advancing. Objective metrics for the analysis of congestion control algorithms are required. Historically, comparision with TCP, i.e., TCP friendliness, has been the metric. TCP friendliness may still be a valid metric if its transitivity can be shown.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

The paper proposes the Datagram Congestion Control Protocol (DCCP), an unreliable transport layer protocol with congestion-control. The authors of the paper motivate the need for DCCP by the increase in applications, such as streaming media and telephony, which utilize the UDP protocol. They point out that application developers are reluctant to implement their own congestion control as it is too complex, but are willing adopt one if it is serviced as a part of a the protocol implemented inside the OS. The paper begins by surveying the range of applications that use a connectionless protocol, such as telephony, streaming media, interactive games and examine the requirements of each. Based on these requirements, the paper presents the following primary goals for DCCP: minimal in both functionality and mechanism, robustness in the face of attackers, NATs and firewalls, support for various application types and provide framework for development, self-sufficiency by providing simple API without application intervention and support for applications requiring fine-grained control. To remove the complexity of a TCP like protocol the authors decide to omit flow control, selective reliability, streams and multicast. The main point discussed in the paper are DCCP’s functioning, its connection management and congestion control.

DCCP is connection-oriented protocol that operates on sequence numbers for invidual datagrams rather than bytes of the packet. The protocol begins with a three-way handshake similar to TCP and a new sequence number is used for every packet. Synchronization packets are used to handle the case where a large amount of packet loss results in unexpected sequence numbers. Acknowledgements are handled in a way similar to TCP except that acknowledgments themselves require acknowledgment like the TCP SACK from time to time. These acks of acks are piggybacked in data packets for two-way communications. Also, acknowledgments do not guarantee delivery of data to the application they are only used as hints of probable packet thus removing much retransmission and making the overall protocol unreliable. The senders are often given the flexibility to choose the length of the sequence numbers used by DCCP to reduce the complexity of their application and make them more sensitive to latencies. On the whole DCCP is proven by the authors to be more robust to sequence number attacks than TCP.

Congestion control in DCCP is divided into two main categories, one that is similar to TCP and mimics its functionality and the other TFRC which is TCP friendly. The TCP-like mode differs in that it also employs reverse-path congestion control. It is achieved by continually changing the frequency of acknowledgments the sender requires. The TFRC mode is a rate-based mode rather than window-based. Acknowledgments are thus required once per RTT and the rate is adjusted accordingly at the same frequency. Several measures included for misbehaving senders and receivers are discussed in the paper. Connection management is made efficient by try to avoid denial of service attacks (DoS) that fill up memory on a server with half-open connections. To address this DCCP is designed so that state information is primarily maintained on the client-side thus avoiding server side burden.

The paper puts forth an important proposition when it is states that designing a congestion control mechanism is complex since Internet router behavior is not fully understood. The paper also highlights the difficulty to decouple reliability and congestion control which are tightly intertwined in TCP thus opening up an argument of DCCP-like protocols which require much effort to deploy going forward. However, the deployment of the ideas presented requires revamp of some TCP ideas and requires implementing them from scratch rather than overlaying them on TCP structure by stripping of its features. The most important point proven in the paper is that even unreliable layer4 protocols cannot completely do away with congestion control since efficient bandwidth usage is of utmost importance thereby opening up an arena research areas which could delve deeper into this philosophy and come up with more protocols that suit applications like telephony, streaming media and the like. Overall the authors do a commendable job of presenting a new protocol to compete TCP in certain applications.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

(i) The three most important things the paper says:

1) DCCP’s decision to use the “latest packet received” for its ackno, and supplement with “Ack Vector” for summary information.  Kohler et al made this decision since when considering protocols without reliability, the latest information is the most important.  However since summary information is still important for congestion control, they added “Ack Vector” which is an additional cumulative history.  This was an important design choice since this feature was the cornerstone for providing congestion control (Ack Vector) at the same time not loosing the importance of acks (used for security, out of order,…).

2) The use of “feedback” in the implementation of TFRC Congestion Control along with how they deal with trust issues with the receiver.  Kohler et al designed this particular implementation of congestion control by using feedback from the receiver.  This solution was keen enough to avoid the “seesaw” problem of TCP like approach, which is not useful for applications such as VOIP.  Although in my opinion this implementation may not be good enough, since using information from the receiver doesn’t take into account other users of the same bandwidth (flow path), it still offers some smarter logic that can be leveraged by higher level protocols.

3) The carefully selected features that it deliberately left out of the design of DCCP which prevents it from making “assumptions” about higher level applications.  However Kohler et al, didn’t do nothing, instead they provided features that better enabled higher level applications.  For instance, their inclusion of “CCID-3” for congestion control can easily be used to add features on top of DCCP for flow control.  I felt this was an important contribution because minimalism and simplicity help with adaptation and security respectively.  Both of which are important for the success of the protocol.

(ii) The most glaring problem with the paper:

The biggest problem with the paper is the section on acknowledgements and saving sate information.  It made the right statement when it said that “pure acknowledgements must occasionally be acknowledged”.  However when asked the question of “infinite regression”, it simply said that it was sufficient to have a single acknowledgement.  This response was not enough to answer the question of “lost acknowledgements”, considering the Byzantine soldier problem.  Since lossyness is ok, I believe they should have added a “timeout” in which they clear the buffer of really old state information.

(iii) The future research directions of the work:

The future research of the work would be in the area of finding a better alternative that resolves the trade off between “short sequence numbers” vs “security”.  At this time, using short sequence numbers (better performance) will leave a bigger window for attackers to inject data.  Considering that, unlike UDP, there is a handshaking step for connection setup and end, perhaps there is some secret information that can be exchanged.  And this “secret Perhaps adding some sort of “pseudo randomness

Designing DCCP: Congestion Control Without Reliability May 29, 2009

Application writers of VOIP, interactive games, and streaming media programs use UDP over TCP since these applications cannot tolerate arbitrary delay and do not require reliability. Using UDP will burden application designers with the need to implement their own congestion control.

The authors present DCCP as a protocol designed for this set of applications with the goals of minimalism, robustness, modular framework for congestion control, self-sufficiency, and support timing-reliability tradeoffs. The authors argue that having each application designer write their own congestion control mechanism is too complex and can be dangerous.

DCCP is connection oriented, support explicit synchronization, has a 48-bit sequence number for security, mobility and multihoming support. Data and ACKs occupy the same sequence space so that ACKs can be acknowledged. The sequence number is incremented at a packet granularity rather than byte granularity. Cumulative ACKs doesn’t make sense in a unreliable protocol so ACK vectors were introduced similar to TCP selective acknowledgements. With this, DCCP can report specific packets received if there were lost packets. ACK vectors can grow to unbounded size so ACKs of ACK vectors will allow the receiver to clear it’s state. DCCP partial checksums can differentiate non congestion related corruption for congestion control over lossy links and also allow for corrupted packets to be accepted.

DCCP implements modular congestion control by negotiating a CCID. CCID = 2 allows for a TCP like congestion control with a congestion window and uses Ack Vectors for feedback. Unlike TCP, ACK  Ratio controls the ratio of data packets per acknowledgement. This provides a reverse-path congestion control and the ratio is capped to provide sufficient timely ACKs. CCID =3 provides TFRC congestion control where instead of a congestion window, the sender uses sending rate and depends on receiver feedback and does not require ACKs for ACK vectors.

The main problem that still needs to be resolved is related to whether routers drop packets or bytes of a packet. This affects the congestion control and fairness at bottleneck routers. The paper didn’t conduct any benchmark for performance differences between applications running UDP w/ own congestion control and DCCP so it’s not clear whether DCCP is a clear winner.

Further research can be done to compare congestion control layer on top of UDP, DCCP, and proprietary protocols. The benefit of a modular congestion control mechanism can open research into new innovation in this area. Further research to resolve middlebox issues can be done to ensure compatibility.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

DCCP is a protocol that provides congestion control without reliability. It is a unicast, connection-oriented protocol with bidirectional data flow. This paper addresses the results of designing a protocol with the new challenges that were not present when TCP was designed. Their goals were to make a very minimalistic, robust and self-sufficient protocol. DCCP had in mind telephony, games and streaming media in it’s design of the protocol. These applications prefer to have occasional losses or corrupted packets instead of the overhead of reliability and checksums.

Major Points:
1.) Sequence Numbers
DCCP must be able to detect losses without application support so sequence numbers need to be used. The sequence numbers are measured in datagrams instead of bytes because it does not need to be reliable. DCCP wants to apply congestion control to acknowledgements, negotiations and connection setup/teardown. To do this every packet occupies a sequence space and uses a new sequence number. DCCP also implements a syncing functionality that can sync the receiver and sender when a large burst of data is lost. Although similar to TCP’s sequence numbers, DCCP found a lot of challenges in just implementing a TCP like sequence number scheme.
2.) Congestion Control Framework
DCCP gives the application a choice of congestion control mechanism. This is important because Internet router behavior is not well specified at the time so there is no right answer for congestion control. With the framework many different congestion control mechanism can be tested. The framework also allows different applications to dynamically change their congestion control mechanism without changing protocols. There are special option fields that help two end points negotiate on which congestion control mechanism to use.
3.) Security
Although security was not a big concern when TCP/IP was designed, it is a huge concern to DCCP. To get around some DOS attacks, DCCP tries to push state to the client whenever possible using something like an Init Cookie option. DCCP can also push Time-Wait state onto willing clients and has rate limits. For misbehaving receivers, DCCP sends an unpredictable nonce value that the receiver should echo back. DCCP also uses 48 bit sequence numbers to deal with sequence number attacks.

Glaring Problem:
The biggest problem I found with this paper is that it did not have any benchmarking experiments. It is hard to believe that this protocol is more important than the related work without seeing results that confirm it is.

Future Work:
DCCP is in the waiting process of whether or not it will be adopted. What makes DCCP a major impact is the congestion control framework that they implemented. Since getting congestion control is a big question mark, researchers can use DCCP’s congestion control framework to implement and use different congestion controls. This will help further research in congestion control techniques.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

Many multimedia applications deal poorly with the TCP protocol because of its retransmission feature. Applications like Internet telephony tolerate much better a packet lost than a delayed one. The natural choice for this kind of applications is to use the UDP protocol. However UDP does not provide any congestion control mechanism. As result, the applications using UDP are forced to implement the congestion control themselves. This makes application development much harder and error prone.

The protocol presented in this paper, the DCCP (Datagram Congestion Control Protocol), addresses the congestion control over an unreliable transport protocol.

The three most important aspects of this protocol are:

1. Congestion control framework. DCCP does not provide a single mechanisms to deal with congestion control. Instead it provides a framework. This allows two end-users to establish the congestion control algorithm they want to use during the handshaking phase. Without constraining the congestion control to a single mechanism, DCCP becomes a very flexible protocol that leaves plenty of room for further optimizations and changes. Being a framework has also two other benefits: first, it facilitates the adoption of DCCP among the set of common transport protocols; second, it allows applications to use the congestion control algorithm that better satisfies their needs.
2. Flexibility. Multimedia application needs can vary broadly. For example, some application may only have a few bits of data to transmit, where others could have a substantial amount. In the former case, the header of the transport protocol should not add too much overhead. DCCP is able to adapt some of its fields, in particular the sequence number field’s length, accordingly to the application’s requirements. In this way it can be adopted by a much wider range of applications.
3. Security. Nowadays protocol must provide security and be as much robust as possible  against attacks. This was not a prerequisite at the time when TCP was created. The authors of DCCP instead set security as one of the main requirements of the protocol. Through a very long sequence number field, explicit synchronization of the sequence numbers between the sender and the receiver and changes in the handshaking and closing connection procedures, DCCP was conceived to be a quite robust protocol that should resist to the most common types of attacks. For instance, DCCP should be able to resist a typical DoS attack because it moved the Time-Wait state from the server to the client, hence preventing the server from running out of resources.

The most glaring point of this paper is that a performance analysis and comparison with existing unreliable transport protocols is completely missing. Indeed the performance of a protocol is as much important as its mechanisms. Another point that is missing is a real test of its robustness against attacks. Accordingly to the paper, the only testing that has been done on DCCP is some sort of formal modeling. As direction for further research I would definitely go through a performance analysis and comparison and then I would try to identify types of applications where DCCP works better or worse than existing solutions.

Designing DCCP: Congestion Control Without Reliability May 26, 2009

This article described DCCP or the Datagram Congestion Control Protocol. This protocol was an attempt by the authors to develop a protocol with the low overhead of UDP but with congestion control built in, similar to TCP. The driving reason behind this was the rapid growth of real time Internet operations such as telephony and streaming media. The key points of this paper were:

1.Congestion control in UDP applications is currently only implemented in the application layer. However, this is problematic due to the fact that congestion control is very difficult to implement correctly, as witnessed by the long evolution of TCP. It is also something that developers would rather not have to deal with, possibly don’t care about (to the detriment of the network) and might possibly implement incorrectly, causing even greater harm. By standardizing a protocol, the implementation would be taken from the developers, theoretically to the benefit of themselves and the network.

2.DCCP is implemented as a flexible framework that allows the developers to choose which method of congestion control suits them best, as opposed to one algorithm that they all must follow. The reason for this is that different applications may have different requirements and the developer is able to tailor the controls to best suit their application.

3.DCCP supports explicit synchronization and packet sequence numbers in order to ensure that the two host do not become out of sync and that the receiver can recognize what packets are relevant. The reason that this is done, rather than the method utilized by TCP is that the unreliable protocol does not need to ensure that every packet is received by the end host. This actually has advantages to the method used by TCP in that connections can by re-synced rather than just reset should an unexpected situation arise.

The main issue that I saw with this paper was the lack of measurements comparing this protocol to TCP and UDP. While I thought that this paper did an excellent job of describing an overview of DCCP, I would have like to have seen them back of their claims, at least to a small degree. This protocol seems like it might have a lot of promise but it will be difficult for operating systems to justify including it and for developers to implement with it if they are not sure that it really will improve performance.

Research in this area is likely to increase as the amount of real-time and streaming data across the Internet increases. People will continue to try to improve on existing protocols in order to optimize their application and maximize the available bandwidth. It does seem interesting that there are only two primary protocols as it would seem that several more could be adopted with minimal confusion in order to more efficiently deal with the traffic of emerging communication trends.