CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Many variants of TCP address the under-utilization problem due to slow growth of TCP congestion window. In large bandwidth-delay product network tackling the fairness issues of new protocols in terms of fairness with respect to existing TCP traffic and fair bandwidth sharing with other competing high-speed flows with same or different round-trip delays (Intra/Inter protocol fairness, and RTT fairness) is addressed in the paper.

TCP fairness is defined as follows: under high loss rate regions where TCP is well behaving the protocol should behave like TCP, and under low loss rate regions where TCP has low utilization problem, it can use more bandwidth than TCP. Most of the protocols have TCP mode in which they behave like TCP. Paper proposes that the regime where TCP performs well should be defined by congestion epoch time (not by window size) which is real-time period between two consecutive loss events.

It notes that though network capacity is in terms of packets but growth should not be characterized in terms of packets because growth rate depends upon the RTT. Hence TCP region of the above mentioned protocols should be defined in terms of real-time.

Paper proposes a variant of TCP which enhances the fairness property of BIC while retaining the scalability and stability. Here window growth function is defined in real-time so that its growth is independent of RTT. Congestion epoch period is determined by the packet loss rate alone. Though TCP throughput is defined by packet loss rate as well as RTT Cubit is defined by only the packet loss rate.

Paper proposes a cubic function of growth along with the linear growth. Window grows very fast upon a window reduction but as it gets closer to Wmax it slows down its growth. Slow growth around Wmax enhances the stability of the protocol and increases the utilization of network while fast growth away from Wmax ensures the scalability of the protocol. Inter flow fairness is maintained because both flows drop by a same multiplicative factor growth function allows that flows with larger Wmax will increase more slowly.

Paper shows that CUBIC has good TCP friendliness and is better stability than other protocols even for rates over 20 Mbps.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

(i) the three most important things the paper says

One important thing that the paper addresses is the fact that congestion epoch time should be taken into consideration when determining protocol behavior, instead of solely relying upon the window size.  The authors claim that the scalability problem in TCP is characterized in real time, and thus real time must be an important part of the computation.  Another point that the authors address (since their implementation is based upon BIC’s) is that BIC might be too aggressive for TCP.  They address this by creating a new window growth function that coexists with TCP much more easily (and fairly).  Another addition to CUBIC from BIC adds a new TCP mode that also helps to emulate TCP on a packet loss event.  The scheme in fact will calculate what the CUBIC scheme thinks that it should do and then also what it believes TCP would do and then chooses the most optimal of the two.

(ii) the most glaring problem with the paper

I feel that the biggest problem with this paper is not in the content of the material but how it’s presented.  I felt that the writing wasn’t very clear and was difficult to understand, which added to the difficulty of the paper.  The paper also didn’t address much background information, but instead jumped right into the meat of the implementation.  This made it very difficult to understand much of the references to other protocols.

(iii) the future research directions of the work

It would be interesting to see how much faster this protocol can be made to converge to an optimal window size without impeding on TCP or causing congestion.  From this paper, I couldn’t tell how much thought was put into optimizing the BIC algorithm in this sense (versus just its TCP friendliness).

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

CUBIC is a variant of TCP which is an enhancement of BIC which provides TCP-friendliness and RTT independent fairness which works well in high bandwidth-delay product networks.

1. CUBIC introduces a new window growth function that is a cubic. The congestion window is determined by Wcubic = C(t-K)^3 + Wmax and is independent of RTT.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

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

1. CUBIC achieves fairness far beyond its competing protocols by using a new window controller that is decoupled from RTT. They model the BIC growth function as a cubic which slows more majorly as fairness is close and reaches that point much faster by modeling the growth as a cubic function rather than a linear function followed by a logrithmic function.

2. This protocol also improves on BIC in terms of TCP friendliness. Because of its low variation as it approaches maximum utilization it allows TCP to continue to grow while not causing packet loss by fluctuization. This means that TCP can grow its utilization without disruption and makes it the most friendly of 4 different protocols analyzed by the author.

3. It is also very important that CUBIC retains the performance of BIC. This was accomplished as shown by the figures that bandwidth utilization of CUBIC is very similar to BIC with less fluctuation. This means that CUBIC has retained the slow increase around the maximum window size and improved the stability of its predacessor.

(ii) The most glaring problem with the paper:

The worst problem with this paper was the writing. The first notable flaw is the paper is extremely repetitive. I dont know how many times they defined what CUBIC was with a similar if not copied definition. The author also includes very little analysis on what these results mean and will allow if the protocol is adopted. He also includes very little future direction of his work.

(iii) The future research directions of the work:

Future research topics should include weather a fair version of BIC is even worth using. The stats presented do not confirm that its utilization of bandwidth is near optimimum but only show that it is fair to itself and that it is friendly to TCP. We should only be transitioning to a new protocol if we feel the throughput gains are especially strong.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

This paper describes CUBIC, a modification to the TCP window growth function. The goal of this is to increase performance after a packet drop without becoming unfair to existing TCP traffic.

The main points of this paper are as follows:

1. The primary motivation for CUBIC (and its predecessor BIC) is that the TCP window usually grows too slowly after a packet-loss-induced multiplicative decrease. This leaves performance on the table unnecessarily, especially when the ideal window size is just below the size that caused the packet drop. CUBIC solves this by using a cubic growth function to rapidly return the window size to near the size that caused the packet drop, while slowing down its rate of growth near that point so as not to overshoot it. If the capacity has increased since the time of the packet drop, the cubic function then enters a cubic growth rate increase, quickly converging on the new rate. This provides the same basic rate detection as normal TCP while converging much more quickly.
2. CUBIC is also offers good fairness to others using the same protocol because the growth rate is tied to the real time of the packet drop. This means that all flows are on equal footing if they have a synchronized drop.
3. While it is friendly to TCP, CUBIC grows the window more slowly on short RTT networks. Therefore they need to modify their algorithm to emulate the TCP algorithm in order to “keep up.” This allows them to be competitive with TCP without being overly aggressive like some of the other protocols are.

The biggest weakness of this paper is that they don’t summarize their work with a clean conclusion. While this could be an artifact of the short paper length, ending on a bunch of graphs does not really state how they achieved their goals.

Future research on this work should evaluate its performance over a larger-scale network, such as the Internet. The variability in BDP and RTT over different hops in the Internet would be a good test of its effectiveness as compared to artificial network topologies.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Three major contributions:

1. A TCP variant that uses a window growth function based on a real-time congestion epoch. (i.e. the real-time between two loss events)
2. A window growth function based on a cubic function. This allows the protocol to be stable, fair across different protocols, and scalable.
3. A TCP variant that reacts to changes in congestion quicker, making it a better suited protocol for high bandwidth networks.

Major problem:

There is a negative incentive to adopt this protocol: in short RTT networks CUBIC’s window growth is slower than TCP. This means that in short RTT networks, flows that use CUBIC will grab less bandwidth than flows using traditional TCP. Secondly, CUBIC claims to have made a simpler window growth function, but both C (the scaling factor) and B (a constant multiplication decrease factor) need to be tuned in order to achieve correct performance.

Future implications:

This protocol still depends on pushing the network to 100% congestion (i.e. packets are lost), but how would you design a protocol that could sense the maximum bandwidth available without having to push the link to capacity? Also, how would you design a protocol that does not have a negative incentive for adoption, but still plays fair with traditional TCP?

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

1. RTT independent growth maintains fairness to TCP

CUBIC defines the instances it enters TCP mode so that fairness with TCP traffic on the node is maintained, based on “congestion epoch time”. This is the time period between two consecutive loss events. Using a constant, time-invarient parameter like window size to determine this transition isn’t accurate and does not take into consideration RTT. Hence when the loss rate is high and/or RTT is small, CUBIC operates in TCP mode.

2.Real-time estimation of window function

The function used to determine window size is determined dynamically so that it is independent of RTT. The function is such that, in case of a decrease, a flow is reduced by a factor proportional to its window size. Hence a flow with larger window size is decreased to a greater extend and that with smaller window size is decremented to a smaller extend. In case of an increase, the opposite is achived, with a flow with larger window increasing to a smaller extend. Hence fairness between flows is maintained.

3. Additive increase in regions far from W_max and logrithmic increase in regions close to W_max

The CUBIC window funtion is such that it makes an estimate of the maximum possible window size. In the vicinity of this maximum, it increasese the window in small increments (logrithmic increase). However, when the currently window size is much smaller or much larger than the estimated maximum, it increses its current window size additively.

Shortcoming

The protocol increases window size by a fixed amount S_max, during the linear increase phase. This still means a large catch up time is involved until maximum utilization is achived. Also, S_max is a constant. Greater efficiency might have been achieved if S_max was varied as a function of RTT and current window size.

Future Work

The protocol could be extended to incorporate flexibility into the variable S_max and S_min. A very basic version of fairness control (fairness between various CUBIC flows) is implemented in the protocol. It could extended to enhance the definition of fairness used in the paper.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

CUBIC is an improvement of the BIC TCP variant. TCP typically increases its window size until loss is encountered. BIC TCP uses an algorithm that increases its window size faster than that of traditional TCP slow start. CUBIC improves on BIC by replacing BICs two stage growth algorithm with a single simpler algorithm. BICs window growth algorithm is also more TCP-friendly and not sensitive to RTT.

CUBIC adjusts its window size based on the elapsed time since the last adjustment. Since RTT is removed from the window scaling algorithm the algorithm enhances fairness among CUBIC flows with varying RTTs. CUBICs windows size grows more slowly that that of TCP over short RTT connections. This enhances CUBICs TCP friendliness.

The short document ends rather abruptly after presenting experimental results. A conclusion that summarizes these results in light of CUBICs novelties would be appreciated.

The CUBIC algorithm shows a great deal of promise especially in light of BICs widespread Linux deployment. Integrating a congestion avoidence mechanism, e.g., TCP-Vegas, could further improve this TCP variant.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Three Important Things:

• CUBIC represents a departure from the traditional TCP notion of ACK clocking for window growth. Instead the growth function is based on real time, effectively decoupling it from RTT and thus making it more deployable on high latency links. On packet loss, the windows size is reduced by a multiplicative factori, and the subsequent growth is a cubic function of time and the old window size. This scheme results in speedy rampup of the throughput and ensures fairness among competing flows. All flows will converge to the same window size because of the proportional decrease
• The paper makes the argument that fair coexistence with TCP is crucial for the deployment of any new high speed protocol. Fairness is defined as behaving like TCP when there is high loss, to ensure that legacy flows are not dominated. CUBIC achieves this by entering TCP compatibilty mode and simulating the multiplicative adjustment of TCP. It essentially reverts to TCP behavior during periods of loss and large relative cmputed window size
• Simulation experiments comparing 5 high-speed TCP variants showed that CUBIC achieved better TCP-friendliness, link utilization, balancing, and stability than any other protocol. This results held across variations of bottleneck bandwidth, RTT, background traffic, and flow competition.

Glaring Problem:

The new protocol is shown to perform well relative to others, and its success relies on several fundamental formulas and appropriately chosen constants. Most of these are presented “as is” in the paper, with little or no formal analysis and justification. There was also no discussion of the methods used to arrive at the material presented, beyond a few vague references to control theory.

Future Work:

The ultimate goal of any TCP protocol is to converge as quickly as possible to the optimal window size while being responsive to changes congestions changes. Graphically speaking this behavior will maximize the area under the throughput curve. Future work should analyze how much better it is possible to do with TCP, meaning that no help is provided from the network. If protocols like CUBIC are getting to close to the point of “as good as can be hoped for” then this should result in a shift of attention to other protocol research possible internet philisophy changes.

CUBIC: A new TCP-Friendly High-Speed TCP Variant May 25, 2009

The paper “CUBIC: A new TCP-Friendly High-Speed TCP Variant” by Injong Rhee and Lisong Xu presents yet another TCP variant building on their previous work on BIC. The goal of the paper is to improve congestion control in TCP by fixing the slow growth of the congestion window in large bandwith-delay product links.

Their first contribution is to base the part of the protocol variant that behaves like TCP (the so-called TCP region) not on window size but on wall clock time. This helps in accustoming the protocol variant to networks with RTT values differing over more than one order of magnitude. The proposed window growth function is a cubic function, which is essentially flat around the origin (which is defined to be the last observed maximum window size). Therefore, the authors have a large area of stability around the maximum window size to reduce oscillation and still have a high rate of change when the network conditions have changed significantly.

The second contribution is an emulation mode for TCP, which emulates the Additive Increase Multiplicative Decrease protocol used in current versions of TCP. This emulation is run in parallel to the window growth function provided by CUBIC, to ensure that CUBIC doesn’t give an unfair share to TCP on small RTT networks.

The last contribution is an comparative study of TCP variants, especially their behavior on networks with different RTTs in respect to the ongoing (old) TCP connections. The authors are able to show that some proposed variants have an heavy impact on TCP connections based on the current implementation, especially for slow link speeds. Finally, the authors look into the stability of the throughput of different variants.

This paper ignores deployment for the new TCP variant and fails to report the impact of the improved TCP friendliness on its own flows.

Future research in this area could involve studying stability and throughput on networks with flows using different TCP variants. This could result in interesting scenarios for the deployment, where compatibility issues might hinder the adoption of certain TCP variants.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Te paper proposes a new transport layer protocol called the CUBIC for high speed networks. CUBIC is an enhanced version of the BIC, but it simplifies BIC window control and improves its TCP friendliness and RTT fairness. The window growth function of CUBIC is governed by a cubic function in terms of the elapsed time since the last loss event. The inherent nature of the cubic function is found to be very well suited in this case and provides good stability and scalability. Also the realtime nature of the protocol keeps the window growth rate independent of the RTT which keeps the protocol TCP firendly under both long and short RTT paths. Although BIC achieves pretty good scalability, fairness and stability under current high networks, its growth function was still too aggressive, especially under short RTTs. Also several different phases of the window growth added complexity in analyzing protocol. CUBIC is proposed as a high speed TCP variant with a cubic window growth function whose shape is very similar to the BIC. The window grows very fast upon a reduction but when closer to maximum window size, it slows down its growth. Thus the slow growth around window max enhances the stability of the protocol while fast growth away from it ensured the scalability. Also CUBIC is found to remain TCP friendly for a much wider range of traffic and RRT than other existing variants of TCP.

Although the paper suggests an improved control function for the window size, its still banking on packet losses as an indication of congestion and does not use explicit congestion signaling. This may lead to slight improvement of the protocol in terms of efficiency, but in the long run will fall behind when the networks becomes really high bandwidth and long latency. Using explicit congestion control mechanism is inevitable under such circumstances.

Future directions of the work may include exploring more control functions and comparing them to find an optimal. The degree of polynimal functions may also be chosen depending on the state of congestion so that the growth is not too aggressive to casue heavy drop of packest while at the same time be efficient enough to utilize the full available bandwidth.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Important Things:
1) CUBIC is a high-speed TCP variant which is shown to be more friendly to TCP than other high-speed variants. It uses a window growth function that depends on real time, independent of RTT. They also emulate TCP’s window adjustment algorithm after a packet loss. They prove (but not in the paper), that their algorithm is fair to TCP for certain values of congestion epoch duration, RTT, and packet loss rate, and that this is better than other high-speed variants.
2) CUBIC retains the stability and scalability of BIC while improving its TCP-fairness and simplifying its window control.
3) CUBIC is evaluated along with four other high-speed TCP variants in simulation (using NS-2), testing for TCP friendliness in short-RTT networks, TCP friendliness in long-RTT networks, and stability. The right metric for measuring stability is not entirely clear, but they conclude that CUBIC shows good stability. CUBIC is also shown to be more TCP-friendly than the other high-speed TCP variants in all cases shown.

Problems:
The TCP-friendliness of all the high-speed TCP variants is very low in long-RTT networks. It may be impossible to maintain TCP-friendliness and have good performance when RTT is high, but whether or not this is the case is not clear to me yet.

Future Work:
All these TCP variants show that protocol design and network design is not an exact science, and it is not clear what is the “right” way to do things. We’ve gotten to this point by just trying different things. Future work should continue the search for the “right” way to network, and this should be done both with backward compatibility in mind (as in this paper), and without.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

This paper introduces a TCP variant whose window growth function is a cubic function in terms of the elapsed time since the last loss event. This growth function is real-time and unlike TCP, its window size calculation is independent of RTT values. The authors note that the under-utilization of TCP is most notably due to its slow start function (especially for short-lived flows where the slow-start function does not have time to utilize available bandwidth). The main contributions of this paper are:

1. An improved window growth function: CUBIC builds on top of BIC and provides a new window growth function. This function grows faster than BIC’s growth function right after a window reduction, and also when probing for the maximum bandwidth. The idea is that after a window reduction, we want to quickly get back to the bandwidth that was assumed to be the available bandwidth, but when we are close to this assumed maximum, we should slow down in order to avoid bandwidth over-estimates. When probing for higher bandwidth, the window size starts off growing slowly, and accelerates its growth quickly as it moves away from the previously assumed maximum.
2. TCP Friendliness: CUBIC aims to be fair to existing TCP traffic. To do so, the protocol emulates TCP window growth algorithm after a packet drop. If TCP’s estimated window size is larger than CUBIC’s window size, then CUBIC simply uses TCP’s algorithm to set the new window size. Also in short RTT networks TCP’s growth function becomes more aggressive, whereas CUBIC’s growth function which is independent of RTT values remains the same; thus it favors TCP traffic under short RTT values because it is passive about RTT values.
3. High utilization while retaining scalability and stability: The independence from RTT values for window size calculation makes CUBIC more stable and prone from oscillations that other variations like STCP face. The fast growth away from W-max (the assumed value for maximum window size) ensures the scalability of the protocol. This is in contrast to TCP’s AIMD policy for window growth. Thus by growing the window much faster than TCP, CUBIC keeps utilization high while scaling better as well.

I can’t think of any major problems with the design, except for the exponential growth of the window size during the “max probing” stage. It seems like when trying to probe for maximum bandwidth, it is easy to overshoot the actual maximum bandwidth by a large factor. Also the authors note that CUBIC behaves less aggressive than TCP in low-RTT environments. This could be a disadvantage for CUBIC hosts when TCP and CUBIC are used together. I’m not sure if their “TCP mode” handles this case or not.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

The paper proposes CUBIC which is a variant of TCP that builds upon the ideas from BIC-TCP and improves its TCP friendliness and RTT fairness

One of the important contributions of the paper is the simpler window growth function. While BIC offered good stability and fairness, its growth function was fairly complicated with the several stages. Also it was more aggressive at the ‘plateau’ or the congestion point. CUBIC solves that through the use of the much simpler cubic function for the window size.

An interesting concept introduced by CUBIC is that it uses real time rather than RTTs for incresing the window size. This allows it to perform better in low RTT networks. When the feedback delay is small, it CUBIC’s window growth is slower than other RTT based protocols like TCP. CUBIC’s window size is dependent only on the congestion epoch or the time between congestion loss events rather than the RTT.

Another important contribution of CUBIC is that it changes the definition of the TCP mode. Rather than using the size of the congestion window as the indicator of the threshold for changing to TCP mode, it uses the actual loss rate and/or RTT estimates to  shift to TCP mode.

One of the flaws of the paper is that it does not provide much insight into the value of empirical constant C = 0.4 which is used to calculate the congestion window size.

A possible direction for future research is to evaluate the performance of CUBIC in extremely low RTT networks like data centers and HPC networks. For high RTTs, although CUBIC is better than the other variants of TCP described in the paper, it still has pretty low fairness at high link speeds. Improving this is essential as networks getter faster and faster.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

CUBIC is an extension to the current standard TCP which simply requires adding an RTT independent TCP mode, to improve the performance of TCP in wire-based large bandwidth-delay product networks. The new mechanisms proposed by CUBIC modify only the window increase function at the sender side, to get high link utilization in a large variety of network conditions. Thus, CUBIC does not impact the Internet security and reacts as standard TCP in case of congestion collapses and routing changes/host dynamics. The main points discussed in the paper are a brief description of BIC which is the predecessor of CUBIC, the description of CUBIC and its performance in terms of TCP friendliness for long and short RTT flows and its stability and scalability.

The underlying principle used in CUBIC is to have a window growth rate that is independent of the RTT of any given flow. This ensures definite fairness when there are different flows competing for the bandwidth of the network. The CWND growth rate function is thus defined only in real-time and its throughput defined only in terms of the loss-rate. BIC uses additive increases followed by binary search below the maximum allowable window size (Wmax) without losses. And above Wmax, BIC uses max-probing which a symmetric opposite of the earlier case implying exponential followed by additive increase. The performance of BIC is due to its slow rate of increase around Wmax and additive increase beyond it but it is limited by the algorithmic complexity posed by the number of sub-stages required and also its partial success for the short-RTT case. At this juncture the paper introduces CUBIC to enhance the operation of BIC wherein a real-time dependent cubic function is used to decide the window size.

CUBIC uses real-time elapsed since the last window reduction and a reduction coefficient that depends on reduced window size after the last reduction. This ensures a slow growth around Wmax just like in BIC but an extremely fast growth away from it thereby giving good bandwidth scalability. Since real elapsed time is used and not the RTT, inter-flow fairness for flows with varying RTTs is guaranteed. The authors conduct experiments to determine the performance of CUBIC for short and long RTT flows and observe that a greater degree of fairness is obtained by adding this new TCP mode. Also, CUBIC is observed to give higher stability by varying buffer space of the bottleneck router for different protocols.

Two problems that are evident from the experimental results shown in the paper are that CUBIC flows sharing the bottleneck converge to the fairness point very late. Also in many cases, CUBIC flows degrade the performance of standard TCP when RTT increases resulting in a significant difference in the fairness of TCP and CUBIC. Despite these limitations CUBIC seems like a good mode to implement over TCP since it has been shown to be far less aggressive than HSTCP and HTCP. CUBIC like the XCP protocol throws open possible alternatives to the conventional TCP flows which face a fairness and scalability crunch when exposed to flows with varying delay-bandwidth products. Furthermore CUBIC calls for researchers to explore better window size scaling functions which smooth out fairness for varying flows and still guarantee stability and scalability.

CUBIC : A new TCP-Friendly High-Speed TCP Variant May 25, 2009

This paper presents a new algorithm for the TCP window control over high-speed networks.

CUBIC tries to address some of the issues left unsolved by other previous TCP implementations  for high-speed networks. The main problem with others TCP implementations is that the congestion control window is very sensitive to the RTT. In particular, if the RTT is very shor, the TCP can increase its window extremely fast, leading to a complete utilization and possibly saturation of the network. This also mean that it can be quite unfair in respect to other packet flows. This flaw of the TCP does not depend on the bandwidth of the link. Tests show that it can saturate a 1Gbps link in 100ms with a small RTT. On the other side, if the RTT is too slow, it could take really a long time for the TCP to converge to a good value for the window.

The CUBIC’s solution addresses these problem with a new window growth function that has the following characteristics:

1. RTT independence. The suggested solution is based not on RTT but on the real time period between two consecutive packet loss events. CUBIC is completely decoupled from the RTT. Hence even a very small RTT does not affect negatively the window growth function. Indeed if the growing factor is bigger than a threshold, the growth gets clumped and proceeds linearly.
2. TCP friendliness and fairness. The window growth function of CUBIC pays much more attention to its growing speed than previous methods, TCP included. This allows CUBIC to be a more friendly and fair approach than HSTCP and BIC, just to name two of them. In particular, the CUBIC’s function grows quite fast when it is recovering after a packet loss. It then slows down and grows almost zero around Wmax, which is the value where the previous packet loss happened. If the flow keeps increasing and no packet gets lost, the speed of the window growth function increases dramatically and it becomes exponentially. In this way, it can scale up very quickly and be able to exploit high-speed bandwidth links.
3. Simplicity. One of the declared advantages of CUBIC over some of its predecessors is its easier growth function. The BIC’s ones, for instance, has many different thresholds to manage and different algorithms during its growth. CUBIC has only one function that is dependent only on the elapsed time since the last packet got lost.

Even if the authors claim that CUBIC’s function is much easier to compute than BIC’s, I would see as an interesting experiment the assessment of the machine overhead, in particular CPU, associated with the computation of the new window with a really high-speed link. Indeed it could potentially become a limiting factor.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

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

1) One of the most important point the paper makes is their focus on “fairness” which remains one of the challenges of new TCP variants.  The first is their consideration of TCP-friendliness to the safety of the protocol.  I believe that Rhee and Xu mention this because, since TCP is the dominating protocol and the adoption of any new protocol hinges on its ability to work well with existing traffic.  Another aspect of fairness that they consider is fairness to other high speed protocols with different RTTs.  This second point is important to maintain stability in the network aswell as not starve another flow (possibly one that is running the same protocol).

2) The choice to use a window groth function that Is definined in real-time independent of RTT.  This is because TCP scabilbitly is more often times defined by real time (e.g. this network takes x amount of times longer than y network…).  Secondly the choice to make the protocol independent of RTT was important to fairness, since growth function will grow for different flows at the same rate.

3) Observing that slow window growth around Wmax enhances the stability and increases the use of the network while fast growth away from Wmax ensure the scalability of the protocol.  These were critical points that they needed to exploit to develop a function to capture these properties.  Also, it was these 2 key observations that allow them to extract the good point from BIC and enhance it to perform even better than it as shown in their results section.

(ii) The most glaring problem with the paper:

The biggest problem with the paper is they mention a lot of observations and comparisons with TCP and TCP variants.  However another dimension to consider would be how a small amount of traffic from a secondary protocol such as UDP may change the characteristics dramatically.  Consider that a randomized bursty UDP traffic may cause the use of “the last lost packet” to have an undesired effect to their cubic function.  For completeness, consideration of the friendliness with at least another two protocol would make this paper much stronger.

(iii) The future research directions of the work:

The future research of the work would be to assume that this has the potential to overtake traditional TCP traffic.  Does it have the versatility of TCP?  For instance could it be used in low speed, high lost, unstable networks?  Or if we must always live in a system managaging two types of TCP variants, what are good algorithms that can be used to determine which TCP variant to use (CUBIC vs traditional).

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

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

1. Many papers have proposed variants to improve utilization during the slow growth portion of the TCP congestion window. The characteristics of a TCP-friendly TCP variant include: fairness with respect to TCP (that is, behave like TCP under high loss, and use more bandwidth than TCP when there is low loss), stability, scalability.
2. The downsides of one of the variants, BIC, is that it is too aggressive in certain situations (such as short RTT and low speed network situations) and there are multiple phases. The proposed variant, CUBIC, uses a single growth function which emulates the shape of the BIC growth function. It simplifies BIC since they do not use multiple phases, and the fact that the function grows independently from the RTT improves TCP friendliness.
3. The authors performed experimental simulations to determine TCP friendliness for CUBIC as compared to four other variants (BIC, HSTCP, Scalable TCP and HTCP) for both long RTT and short RTT networks. In both cases, CUBIC exhibited the best throughput ratios, though TCP friendliness for all variants declined rapidly at higher link speeds in long-RTT networks.

(ii) The most glaring problem with the paper:

From result of the NS simulation, it appears that CUBIC is slow to converge to a fair share (it seems to me that 220 seconds is a long convergence period. Furthermore, experiment 3 (the stability experiment) seemed a bit weaker since the authors cannot define a clear stability measure.

(iii) The future research directions of the work:

It might be interesting to see the behaviour of CUBIC for different types of traffic patterns and more flows, as well as real traffic. More satisfying measures of stability might be helpful to bolster the authors’ claims on the stability of CUBIC.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

(i) Three most important things

1. The TCP window growth function should be defined in real-time, the elapsed time since the last loss event.  Packet count is not adequate to characterize TCP performance because the growth rate of TCP depends on RTT. TCP can grow the window up to the full utilization of the network within 100 ms, if RTT is 1 ms and protocols like HSTCP, STCP, and BIC could possible consume bandwidth unfairly over other competing TPC traffic. The paper presents a new TCP variant called CUBIC that defines the window growth function in real-time so that growth will be independent of RTT.

2.  By keeping the window growth rate of TCP independent of RTT, TCP friendliness improves. The window growth function of RTT dependent protocols like TCP grows proportionally faster in shorter RTT networks whereas CUBIC will grow independently of RTT. Since TCP gets more aggressive while CUBIC remains unchanged, short RTT will make CUBIC more friendly to TCP.

3. By keeping the window growth rate of TCP independent of RTT, RTT fairness improves. The cubic function of CUBIC ensures the intra-protocol fairness among competing flows of the same protocol since different RTT flow will still grow their windows at the same rate.

(ii) Most glaring problem

The most glaring problem would be that the experiments on the various TCP variants compared were tested in short RTT networks and long RTT networks but these situations aren’t necessarily realistic. CUBIC should be tested in a real network environment.

(iii) Future Research Directions

Future research directions for this work would be to study other choices for the window growth function and compare these choices to CUBIC and determine if and what makes CUBIC better than the others.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Cubic is a new TCP variant that improves TCP-friendliness and RTT-fairness. The main difference of Cubic is that it uses a cubic function to govern the window growth function and it uses real-time that makes window growth independent of RTT which keeps the protocol TCP-friendly under short and long RTT. This is important in trying to utilize the most of the network.

Major Points:
1.) Cubic Window Growth Function
The authors show that the BIC window growth function is too aggressive because the jump to the midpoint of the max Window and min Window during a packet loss can be too large within one RTT. To get around this, Cubic is a cubic function that uses a bunch of constants, Wmax and the time elapse from the last window reduction. This cubic function will have the window grow fast upon a window reduction but as it gets closer to Wmax is slows down it’s growth. The fast growth before window reduction helps the protocol scale while the slow growth to Wmax increases the utilization of the network.
2.) RTT Fairness
The main difference between other TCP variants is that Cubic uses real time instead of RTT. The window growth is dominated by t which is the elapsed time. This is fair because any competing flows with different RTT’s will have the same elapse time t. They use a Smax time to make sure that the window grows linearly when it is far away from Wmax.
3.) New TCP Mode
Most protocols that rely on RTT grow faster with a shorter RTT while Cubic grows independently of RTT. To get Cubic to act like TCP, they just alter some constants to get similar growth rates and window sizes. The main thing to take from this is that compared to other protocols, Cubic has a wider range of friendliness with TCP. Their experiments back up this claim.

Glaring Problem:
They don’t really explain why a cubic function was chosen over any other odd function. What are the advantages of a cubic function over a higher odd function. It seems like Cubic might take a long time to converge but this is not a big deal as the network is always changing.

Future Work:
As more and more people are getting onto the internet, utilization will become a big problem. Cubic can help utilize the network with TCP and RTT fairness that is more and more important with more people going online. They are also working on figuring out a good time scale to see if a protocol is scalable.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

i)

1. CUBIC grows the window in real time rather than just based on RTT. This allows it to grow the window regardless of RTT time. The benefit of this is, in networks with a high RTT, CUBIC will grows its window quicker than TCP, thus not having to incur high delays before the window reaches an optimal size.

2. CUBIC uses a cubic function to grow the window after a packetloss event that emulates the curve from BIC. The benefit of using a cubic function is that if the packetloss was really due to on-going congestion, the window will only be grown slowly and if the congestion is on-going, continued packetloss will be detected. However if the packetloss was due to simply transient congestion, CUBIC will soon start growing the window by large amounts, allowing it to quickly recover to the old bandwidth it was using.

3. CUBIC is the most TCP friendly of the high speed TCP variants. This allows CUBIC to coexist along side TCP while still providing high-speed performance to its users. However in networks with a long RTT, the TCP friendliness is significantly less than what it is in networks with a short RTT. This is primarily due to the fact it scales with congestion window in real time rather than based on RTT intervals.

ii) I think one of the major flaws is the unfairness to TCP in high RTT networks. CUBIC is now the default TCP implementation in Linux and in high RTT networks such as the internet, as CUBIC becomes more prevalent it seems like it has the potential to choke the bandwidth available to older TCP implementations.

iii) It appears that TCP is poorly suited to congestion control. I think there still needs to be much research on an improved congestion control mechanism. I think ultimately ISPs are in the best position to deploy a congestion control mechanism that does not require cooperation from the end hosts.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

The paper proposes an improvement to the window growth function in BIC. The TCP variant is called CUBIC because the window growth function is a cubic function. There is really only 1 main contribution in this paper. The contribution is that by using a cubic function based on real time instead of RTT, CUBIC behaves more fairly to other TCP flows than BIC.

Window growth in BIC is governed by an algorithm that switches between additive increase and logarithmic search to maintain a maximum congestion window. CUBIC’s growth function achieves roughly the same using a less complex algorithm, but does so using real time instead of RTT as the independent variable. This results in a less aggressive, and thus more fair, utilization pattern because short RTTs do not grow the window to wide too quickly. Similarly, long RTTs don’t slow the growth unnecessarily. This also seems to result in a more “stable” protocol (as measured by the coefficients of variance).

The big problem with this incremental improvement to BIC is that it does not take RTT into account for the purposes of detecting buffering (as say TCP Vegas does). Indeed, CUBIC represents an improvement over BIC, but it still causes congestion in the network during probing.

I’d expect future work would include the RTT for purposes of identifying the congestion window max size without causing congestion. This combined with CUBIC’s less aggressive growth function would probably produce a more TCP fair protocol.