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

Internet Congestion Control for High Bandwidth Delay Product Networks May 19, 2009

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

 

1) The concept of decoupling utilization control from fairness control was a novel idea in this paper.  This stemmed some good points, for instance, opening up new avenues for service differentiation.  This was an important point from a business perspective, since ultimately what drives the deployment of new technology will hinge on large corporations adopting it.  Another good point is how this separation simplifies the design and analysis of each controller by reducing the requirements imposed. 

 

 

2) Since congestion is not a binary variable and requires a degree of values to truly measure it, the protocol must reflect this as well.  Because of this, Katabi et al ultimately decided to use a precise congestion signaling where the network tells the sender the state of congestion. From my perspective, this is the cusp of XCP since it allows them to have amazing results such as “rarely loosing packets” and “efficient use of bandwidth in a multitude of conditions”. 

 

3) The method in which they implemented XCP, a protocol based on network control of flows, with little overhead to routers.  By storing feedback information in a header, and making routers “stateless”, they estimated that a XCP router only performed a few additions and 3 multiplication per packet.  This is important as we are demanding faster routers and switches at the edge of our networks, any additional overhead may make a solution no longer viable.

 

(ii) The most glaring problem with the paper:

 

Although the paper considered security aspects and how to detect senders that do not honor XCP, they do not consider the cases of rouge routers.  Since this is a protocol that relies on the network (aka routers) from making the right choices, I believe that router security should be considered more.  Specifically, consideration of methods to avoid paths that routes through a router that you know is making poor or malicious decisions.  This is pivotal before XCP can be deployed in a commercial setting, since a single rouge router can trick the rest or the routers to believe that senders are misbehaving.

 

(iii) The future research directions of the work:

 

They seem to be very proud on the fact that in their tests, XCP rarely loose packets.  I believe this may have been a blind spot in their research.  A good direction for the research would be to analyze more dimensions of tests that involve XCP behavior in low reliability networks.  Since they aim to replace TCP, this is an important facet to cover the flexibility of this protocol.

TCP Vegas: End to End Congestion Avoidance on a Global Internet May 15, 2009

The paper by Brakmo and Peterson out of University of Arizona introduces a new TCP implementation, which improves on congestion avoidance mechanisms in TCP. The authors present the new techniques in contrast to the older TCP implementation called Reno, and evaluate simulation and measurement results of the two implementations. The three key techniques in Vegas are:

1) Retransmission mechanism: In both implementations, the goal is to avoid relying on coarse grained timers, and allow faster retransmission of lost packets in between coarse timer ticks. In Reno, this simply happens after three duplicate ACKs for an old packet are received. In Vegas, a timestamp is recorded for each sent packet and when the appropriate ACK for this packet is received, the Round-Trip-Time is updated. This RTT is used to see whether the first duplicate ACK already indicates a packet loss (because it arrives later than the estimate arrival time of the ACK of the lost packet) or if the first two ACK packets after a retransmission are also late, in which case more packets have been lost shortly before retransmission.

2) Congestion Avoidance: The authors describe Reno as an reactive implementation in the sense that Reno always pushes the bandwith over the “limit” of the optimal bandwidth by filling up router buffers on the way until packet loss occurs. This leads to oscillations in the send speed over long-going connections, filling up buffers unnecessarily. Their Vegas implementation, in contrast, tries to be proactive when increasing or decreasing the send window size. It does this by calculating the Expected and Actual throughput when changing the send window size, to find out if increases or decreases are necessary. This is done by comparing the rate to thresholds, so unnecessary oscillations are avoided.

3) Slow-Start: To optimize the slow-start period in TCP, the authors propose to use the congestion avoidance mechanism also during the slow-start phase, changing also the point in time where the send window size is doubled. This can only happen in Vegas once every two RTT, whereas Reno did it every RTT. This slows down the start a little, but avoids overshooting the available bandwith and reduces the need for retransmission.

The most glaring problem of the paper is the fact that the simulations don’t take different networks into accounts, no variations of the delay or available bandwith are simulated. Seeing the behavior in a multi-hop simulation with changing environmental conditions would have made a stronger point.

Future research directions for these TCP mechanisms are looking into congestion avoidance mechanisms that have minimal support from the routers on the way, which can signal end hosts and warn them about upcoming congestions or there optimal sending rate in a more direct way. These mechanisms could be simulated and evaluated.

TCP Vegas: End to End Congestion Avoidance on a Global Internet May 15, 2009

The paper introduces TCP Vegas and compares it against TCP Reno in terms of throughput and retransmission rate. The results show that Vegas makes uses of available bandwidth and avoids congestion (indeed avoids creating congestion) more effectively than Reno. Furthermore, these results are not at the expense of other non-Vegas TCP flows. TCP Vegas achieves these results even when all the flows are TCP Vegas flows.

The major contributions of Vegas are a new algorithm for determining retransmission, a new measurement for detecting (and thus avoiding) congestion, and a modified slow start mechanism that avoids overrunning bottleneck router buffers.

The new retransmission algorithm uses system clock timestamps to estimate RTTs instead of the BSD-based 500ms “ticks”. This means RTT estimates are more accurate. Further, Vegas uses ACKs to check if a timeout has occurred instead of waiting for a “tick” to pass. Lastly, instead of waiting for n (3) duplicate ACKs to be received before retransmitting, Vegas retransmits after the RTT has been exceeded.

The second contribution is the new congestion avoidance mechanism. Using a base RTT and accurately measuring the change in RTTs between segment sends and ACKs, Vegas can calculate an expected and actual throughput. Vegas then defines two thresholds, a lower and upper threshold. By adjusting the send window size to keep the throughput between the lower and upper thresholds, Vegas can keep between 1 and 3 segments in the bottleneck router’s buffer full. This means Vegas can effectively utilize available bandwidth without overrunning the bottleneck router’s buffer.

Lastly, Vegas uses the expected and actual throughput measurements to avoid overrunning the bottleneck router’s buffers during slow start. Instead of doubling the window size every RTT, Vegas doubles every other RTT. Every other RTT, it measures the throughput. If the throughput begins to decrease, Vegas switches to linear growth mode to avoid causing congestion in the network.

It seems clear from the results presented that TCP Vegas is a better implementation of TCP than TCP Reno. However, it would also seem that TCP Vegas is considerably more difficult to implement. The algorithms for the improved features are more complex than even TCP Reno (which is by no means simple).

I’d like see how quality of service implementations/mechanisms work with Vegas. Because Vegas is very adept at consuming available bandwidth without causing congestion, I expect that some QoS implementations will suffer because of the lack of “slack” bandwidth now available.