Difference between revisions of "GSOC2017Tcp"

From Nsnam
Jump to: navigation, search
(Week 1 (May 30 - June 5))
(Week 2 (June 6 - June 12))
Line 126: Line 126:
 
1. ECT flags should be set for SYN, SYN+ACK, pure ACK and data packets for DCTCP traffic
 
1. ECT flags should be set for SYN, SYN+ACK, pure ACK and data packets for DCTCP traffic
  
2. ECT flags should not be set for SYN, SYN+ACK and pure ACK packets, but should be set on data packets for non-DCTCP but
+
2. ECT flags should not be set for SYN, SYN+ACK and pure ACK packets, but should be set on data packets of ECN enabled  
ECN enabled traffic
+
traditional TCP flows
  
3. ECE should be set only when CE flags are received at receiver and even if sender doesn’t send CWR, receiver should not  
+
3. For DCTCP flows, ECE should be set only when CE flags are received at receiver and even if sender doesn’t send CWR, receiver should not  
 
send ECE if it doesn’t receive packets with CE flags
 
send ECE if it doesn’t receive packets with CE flags
  
Line 136: Line 136:
 
5. Decrement Test : Verified the computation of alpha and congestion window reduction
 
5. Decrement Test : Verified the computation of alpha and congestion window reduction
 
</pre>
 
</pre>
* Tested the code on src/traffic-control/examples/red-tests.cc file by modifying MinTh and MaxTh to be 17% of QueueLimit and QW parameter as 1
+
* Tested the working of DCTCP on src/traffic-control/examples/red-tests.cc file by setting m_minTh and m_maxTh to be 17% of QueueLimit and m_qw parameter to 1
 
* Issues :  
 
* Issues :  
 
<pre>
 
<pre>
 
1. Test case 3 is failing and I am currently trying to solve this bug
 
1. Test case 3 is failing and I am currently trying to solve this bug
  
2. Should ssthresh be set to cwnd(1-alpha/2) when congestion window is reduced in DCTCP? ns-2 code follows this but IETF  
+
2. Should ssthresh be set to cwnd(1 - α / 2) when congestion window is reduced in DCTCP? ns-2 code follows this but IETF  
 
document for DCTCP hasn’t thrown any light on this. This is an open question.
 
document for DCTCP hasn’t thrown any light on this. This is an open question.
 
</pre>
 
</pre>

Revision as of 10:29, 20 June 2017

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 2017 Accepted Projects page.

Project overview

  • Project name: Framework for TCP Prague simulations in ns-3
  • Abstract: Recently, there has been a lot of interest in the research community (IRTF / IETF) towards parallely implementing and standardising a new TCP extension called TCP Prague, which is targeted to be an evolution of Data Center TCP (DCTCP). DCTCP starves the throughput of other TCP flows (e.g., Reno, Cubic, etc) when they co-exist; so one of the goals is to ensure that TCP Prague can co-exist with other TCP flows without degrading their throughput. Although TCP Prague is still a work in progress, some related modules have been finalised and briefly experimented, such as: the Low Latency, Low Loss, Scalable throughput (L4S) service architecture, DualQ Coupled AQM, Modified ECN Semantics for Ultra Low Queuing Delay. Availability of these modules in network simulators like ns-3 is crucial to boost up the ongoing efforts of standardising TCP Prague. In this project, the aim is to implement the above mentioned modules in ns-3. Additionally, the functionality of these modules will be tested, and the necessary documentation with some examples will also be provided.
  • About me: I have completed my BTech. in Computer Engineering from National Institute of Technology Karnataka (NITK), Surathkal, India. I will be pursuing MS in Networks at CMU from August, 2017 . I have been working in ns-3 for the past 2 years. I have worked on "ECN Support for ns-3 queue discs" during ns-3 Summer of Code, 2016 and "AQM Evaluation Suite for ns-3" as Bachelor's thesis.

Technical Approach

ns-3 supports a rich set of TCP extensions, but lacks those which generate L4S traffic, such as DCTCP. Thus, the first phase of the project would comprise of implementing DCTCP to provide support for simulating L4S traffic in ns-3. This will be followed by testing, documentation and development of examples for DCTCP. In the second phase, topology helpers to set up basic data center topologies such as Fat tree and BCube will be provided, which would help users to quickly setup an environment for Data Center Networks (DCNs) in ns-3. The necessary trace sources required to easily fetch the data from simulation will also be provided in this phase. In the third phase, DualQ Coupled AQM will be implemented by using PI2 as a queuing discipline. Although there is an implementation of PI2 for ns-3 which is currently review, it cannot differentiate between the classic traffic and L4S traffic i.e., it lacks the DualQ functionality. Thus, the existing implementation of PI2 will be extended to support DualQ functionality. Lastly, the existing implementation of ECN in ns-3 will be extended to complement the DualQ functionality, and provide a complete framework ready to be used for future TCP Prague experimentation.

Milestones and Deliverables

The entire GSoC period is divided into 3 phases. The deliverable at the end of each phase is as mentioned below :

Phase 1

  • Implementation of DCTCP algorithm
  • Testing of DCTCP model and documentation
  • Provide examples for DCTCP

Phase 2

  • Implementation of topology helpers
  • Implementation of necessary trace sources
  • Provide NetAnim examples for topology helpers

Phase 3

  • Extending the existing PI2 implementation
  • Testing of extended PI2 model and documentation
  • Implementation of Modified ECN
  • Testing of Modified ECN
  • Integration of TCP models and extended PI2 AQM with Modified ECN
  • Provide examples to simulate TCP Prague

Weekly plan

Community bonding period (May 4 - May 29)

  • Contact mentors and update weekly plans based on suggestions.
  • Prepare wikipedia page for the project explaining the details of the project
  • Prepare architecture for implementation of all components and get reviews from mentors

Week - 1 (May 30 - June 5)

  • Implementing sender side functionality of DCTCP
  • Implementing receiver side functionality of DCTCP
  • Implementing router side functionality of DCTCP

Week - 2 (June 6 - June 12)

  • Testing sender side functionality of DCTCP
  • Testing receiver side functionality of DCTCP
  • Testing router side functionality of DCTCP

Week - 3 (June 13 - June 19)

  • Complete the documentation of DCTCP implementation
  • Develop example programs for DCTCP

Week - 4 (June 20 - June 26)

  • Prepare a patch for DCTCP implementation in ns-3 and send it for review
  • Prepare for first mid term review

Week - 5 (June 27 - July 3)

  • Implementation of Fat tree topology helper
  • Implementation of BCube topology helper

Week - 6 (July 4 - July 10)

  • Implementation of necessary trace sources
  • Provide NetAnim examples for topology helpers

Week - 7 (July 11 - July 16)

  • Complete the documentation of topology helpers
  • Address comments of first review

Week 8 (July 17 - July 23)

  • Prepare a patch for topology helpers implemented in ns-3 and send it for review
  • Prepare for second mid term review

Week - 9 (July 24 - July 30)

  • Review the existing implementation of PI2
  • Extend PI2 implementation with necessary classification features

Week - 10 (July 31 - August 7)

  • Test the extended PI2 implementation and complete the documentation
  • Prepare a patch for extended PI2 implementation and send it for review
  • Address comments of second review

Week - 11 (August 8 - August 14)

  • Implement the Modified ECN in ns-3
  • Test the Modified ECN implementation and complete the documentation
  • Prepare a patch for Modified ECN implementation and send it for review

Week - 12 (August 15 - August 21)

  • Integration of TCP models and extended PI2 AQM with Modified ECN
  • Provide examples to simulate TCP Prague
  • Bug fixes, final documentation and prepare the code to merge

Weekly Progress

Week 1 (May 30 - June 5)

  • Modified tcp-socket-base.cc: For DCTCP connections, the sender should set ECT for SYN, SYN+ACK, ACK and RST packets, besides the typical data packets. (Section 3.5 of Internet Draft on DCTCP)
  • Implemented tcp-dctcp.cc and tcp-dctcp.h files in src/internet/model with following functionalities :
* Functionality at the receiver: Check if CE bit is set in the IP header of incoming packet, and if so, send congestion 
notification to the sender by setting ECE bit in TCP header.

* Functionality at the sender: The sender should maintain a running average of fraction of packets marked (α) by using the 
traditional exponential weighted moving average as shown below:

               α = (1 - g) x α + g x F

where g is the estimation gain (btwn 0 and 1) and F is fraction of packets marked in current RTT. On receipt of an ACK with 
ECE bit set, the sender should respond by reducing the congestion window as follows, once for every window of data:

               cwnd = cwnd * (1 - α / 2)

Week 2 (June 6 - June 12)

  • Designed test-suite for DCTCP and implemented the following test cases :
1. ECT flags should be set for SYN, SYN+ACK, pure ACK and data packets for DCTCP traffic

2. ECT flags should not be set for SYN, SYN+ACK and pure ACK packets, but should be set on data packets of ECN enabled 
traditional TCP flows

3. For DCTCP flows, ECE should be set only when CE flags are received at receiver and even if sender doesn’t send CWR, receiver should not 
send ECE if it doesn’t receive packets with CE flags

4. Increment Test : DCTCP should function like NewReno during slow-start

5. Decrement Test : Verified the computation of alpha and congestion window reduction
  • Tested the working of DCTCP on src/traffic-control/examples/red-tests.cc file by setting m_minTh and m_maxTh to be 17% of QueueLimit and m_qw parameter to 1
  • Issues :
1. Test case 3 is failing and I am currently trying to solve this bug

2. Should ssthresh be set to cwnd(1 - α / 2) when congestion window is reduced in DCTCP? ns-2 code follows this but IETF 
document for DCTCP hasn’t thrown any light on this. This is an open question.

Week 3 (June 13 - June 19)

  • Fixed the following bugs related to DCTCP implementation
* tcp-dctcp-test.cc was crashing due to test 3. I fixed it by making corrections in  the Rx and Tx functions of the test 
suite to correct this

* The test suite would crash if the traffic for DCTCP was not ECN capable. Therefore, SetEcn() was called in constructor 
of DCTCP rather than addition of SetDctcp() function which would set ECN

* Cestate1to0 function in DCTCP was called when ECN state was ECN_DISABLED. Condition was added to prevent this
  • Cleaned the DCTCP code, test-suite and documented it
  • Developed an example file for DCTCP called dctcp-dumbbell-example.cc and it is placed in examples/tcp
  • Designed the architecture for implementation of B-Cube topology