GSOC2015TCPTest

From Nsnam
Revision as of 09:51, 30 April 2015 by Natale (Talk | contribs) (Created page with "{{TOC}} Return to GSoC 2015 Accepted Projects page. == Project overview == * '''Project:'''TCP layer refactoring with automated test on RFC-com...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

Return to GSoC 2015 Accepted Projects page.

Project overview

  • Project:TCP layer refactoring with automated test on RFC-compliance and validation
  • Student: Natale Patriciello
  • Mentors: Tom Henderson,Tommaso Pecorella
  • Abstract: A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.
  • Future Plans: None yet
  • Code:
  • About me: My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [here]

The (original) proposal

Actual TCP Overview

The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.

Considerations

Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control "is-a" TCP (e.g. TcpNewReno "is-a" TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.

Tests

An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: "What happen if the 14th packet is lost?". The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.

The complete proposal

Read (and comment) the entire proposal [here].


Expcted deliverables

Week 1 - Step 1

  • Time measurement on TCP layer
  • Remove the TcpL4Layer and TcpSocketBase friendship (which become an "has" relationship)

Week 2 - Deliverable for Step 1; start of Step 2

  • Patches submitted for deliverables of step 1
  • Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.
  • Actual test updated to account this design

Week 3 - Step 2

  • Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.
  • Port of existing congestion control as subclasses of TcpCongestionControl

Week 4 - Step 2

  • Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)

Week 5 - Deliverable for Step2 and Step 3

  • Subclassing is done through "virtualization" of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.

Week 6 - Step 3

  • Carry on on the splitting, with a careful check when splitting duties

Week 7 - Deliverable for Step 3; start of Step 4

  • From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.
  • In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.

Week 8 - Step 4

Week 9 - Step 4

Week 10 - Step 4 and Deliverables for Step 3 and 4

  • Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)


Weekly progress

Final review