Performance of DBCEs Across Clusters

We next study the per-cluster performance of all the candidate DBCEs. Figures 5.18–5.29 plot the reduction in connection duration estimated using the additive CA policy for the Vegas, CIM and Tri-S DBCEs (the observations for multiplicative CA are similar). Cluster 5 behaves very similar to Cluster 1 and is omitted. The observations seen with the other DBCEs are similar to one of these three DBCEs

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

cim

Figure 5.22: CIM: Impact on Connection Du- ration (Add CA) on Cluster 1

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

cim

Figure 5.23: CIM: Impact on Connection Du- ration (Add CA) on Cluster 2

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

cim

Figure 5.24: CIM: Impact on Connection Du- ration (Add CA) on Cluster 3

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

cim

Figure 5.25: CIM: Impact on Connection Du- ration (Add CA) on Cluster 4

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

tri

Figure 5.26: Tri-S: Impact on Connection Du- ration (Add CA) on Cluster 1

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

tri

Figure 5.27: Tri-S: Impact on Connection Du- ration (Add CA) on Cluster 2

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

tri

Figure 5.28: Tri-S: Impact on Connection Du- ration (Add CA) on Cluster 3

-100 -10 -1 +/-.1 1 10 100 1000 <1 10 100 1000

Actual Change in Connection Duration (in RTTs)

Best-case Change in Connection Duration (in RTTs)

tri

Figure 5.29: Tri-S: Impact on Connection Du- ration (Add CA) on Cluster 4

(in exactly the same way as seen in Section 5.4.3). We find that:

• Across all DBCEs, Cluster 2 has the best performance in terms of the number of connections that witness a reduction in connection duration; this is especially true for connections with best-case reduction in connection duration within 100 RTTs.

• For connections with a larger best-case potential, Cluster 4 performs better with CIM—in fact, in this case the median reduction in connection duration is fairly close to the best-case.

For Vegas and Tri-S, the performance of Cluster 4 is similar to that of Clusters 1, 3, and 5. • The impact on connection duration with Vegas is zero for almostallconnections in Clusters 1, 3,

4, and 5. Only in Cluster 2, do a significant fraction of connections see a significant reduction in connection durations (by more than 10 RTTs). The only distinguishing characteristic of Cluster 2, not present in any other cluster, is the noticeably large median flight sizes.

From the above observations and Table 5.4, we conclude that (i) connections with high throughput and large flight-sizes (Cluster 2) are likely to benefit the most from any DBCE; (ii) for DBCEs (such as CIM) that perform well on an average among existing DBCEs, a high-throughput connection can perform better with smaller flights if its loss-rate is low (Cluster 4); and (iii) the estimator of the prominent Vegas protocol is fairly conservative and has an impact only on connections that have large flight sizes. We find that the other connection-characteristics do not have any significant impact on DBCE performance.

5.6

Concluding Remarks

We conduct a large scale study with a diverse set of TCP connection traces where we extract the RTTs seen by each connection and used them to evaluate eight prominent delay-based congestion estimators (DBCEs). We tested each estimator’s performance in terms of (i) the loss prediction ability (LPA), (ii) fraction of erroneous congestion prediction (false positives), and (ii) the overall impact on connection duration when the DBCE is used in congestion with congestion-avoidance. We also cluster our connection traces using several connection characteristics that are likely to impact the performance of DBCEs; we then study the per-cluster performance of DBCEs. Our main findings are:

• CIM is the overall best estimator. It is likely to reduce the durations of large connections signifi- cantly, though at the possible expense of small connections.

• The estimator used by the prominent Vegas protocol is fairly conservative. It has absolutely no impact on the durations of TCP connections that do not transmit large flights of segments. • Connections with a high throughput and large flight-sizes are likely to benefit the most from any

DBCE.

Our high-level conclusion is that the state-of-the-art in delay-based congestion estimation can be im- proved upon by designing an adaptive DBCE that considers the characteristics of a TCP connection and those of the path it traverses to select either an aggressive or a conservative estimator. Our passive analysis approach does not allow us to study the interaction between delay-based congestion-control and network cross-traffic. We hope to address this using an active experimental framework in the near future.

CHAPTER 6

Conclusions and Future Work

The important thing is not to stop questioning.

—Albert Einstein (1879–1955)

A conclusion is the place where you got tired of thinking.

—Harold Fricklestein

Even though TCP has been around for decades and several studies have looked at the performance of TCP under different conditions, its actual performance in the “real world” is not really well understood. This is especially true for its loss detection and recovery mechanism. The main reason for this is the difficulty of studying TCP behavior in a detailed manner on the real Internet. In this dissertation, I have made a systematic attempt to address this shortcoming to conduct detailed analysis. I believe this work is a significant step in the right direction and provides several insights to modify current TCP implementations as well as to design new better protocols. However, this work is by no means complete. In this Chapter, I will highlight some of the key contributions/results of this dissertation, discuss the implications of these results and suggest future avenues to explore.

6.1

TCPdebug

One of the key contributions of this dissertation is theTCPdebugtool we developed for the passive analysis of TCP. This tool can be used to analyze large traces quickly and accurately. TCPdebug not only integrates several important analysis techniques proposed in the literature but also covers several corner cases ignored by the previous tools. However, the main innovative feature of this tool is the use OS specific TCP implementation details for TCP analysis. TCPdebugmodels the TCP implementation- specific behavior of four Operating Systems (Windows, Linux, FreeBSD/MAC OS X, Solaris) that are currently (and likely to be in the foreseeable future) the dominant end-systems for TCP connections.

The tool is designed to provide a very detailed classification of the out-of-sequence segments seen in real world traces. It also tracks several key characteristics of a trace such as the Round Trip Times (RTTs), packets in flight and advertised window.

This tool is extensively validated using a controlled setting as well as using large number of real traces. The tool is found to be accurate in 99+% of the cases. This is almost a 100% improvement over the current state of the art for TCP analysis tools. TCPdebugis freely available to the networking research community and we hope they will encourage others to contribute to our understanding of TCP behavior “in the wild” by analyzing larger and more diverse sets of traces. The tool is also designed to be easily extensible and new features like tracking congestion windows can be easily implemented. In fact, we ourselves have extended this tool to include the algorithms used by several delay based congestion control schemes to predict network congestion. The tool is quite fast and can process several gigabytes of compressed packet header traces in minutes once they are sorted (sorting itself is not a hard requirement and the tool can be easily modified to remove this requirement).