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

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

(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

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

(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.