Simulating TCP with OMNeT++

For the past several years, ns-2 has been the predominant packet-level simulator used by academics in the US. Because TCP was also developed in the West by academics, ns-2 has become a reputable simulator of TCP. In fact, ns-2 has become a sort of paragon for how TCP should behave. A SIGCOMM paper written by Kevin Fall and Sally Floyd in 1996 uses ns-2 to demonstrate the behavior of four different types of TCP when packets are dropped. They use graphs from the simulator's output to show how Tahoe, Reno, New-Reno and SACK respond to one, two, three, and four induced packet drops. Fall and Floyd's paper not only proves helpful in showing how TCP behaves with packet loss, but also can be used as a benchmark for a correct TCP implementation.

We decided that we would try and replicate the results of Fall and Floyd using OMNeT++, an open-source simulator developed primarily in Europe and the East. OMNeT++ is a growing simulator, and it is not restricted to only network simulations. Since OMNeT++ is less common in the West, we were interested in how its implementations of TCP compare with those of ns-2. We used the network modules from the INET package, and ran simulations of Tahoe, Reno, New-Reno and SACK TCP with one, two, three and four drops. A thorough description of our simulations and findings is given in this paper.

We learned that INET's Reno behaves identically to that of ns-2, that INET's NewReno and SACK behave similarly to ns-2's, but INET's Tahoe implementation has some oddities. With two or more packet drops, INET Tahoe tends to time out rather than resume a typical SLOW-START as it should. As far as OMNeT++'s ability to scale, we were able to run 1,000 simultaneous TCP transfers with the simtime:time ratio of approximately 1:170. We conclude that OMNeT++ can simulate TCP reasonably in most cases, and can scale reasonably. Also, INET Tahoe implementation should be improved.