https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&user=ApoorvaBhargava&feedformat=atomNsnam - User contributions [en]2024-03-29T02:26:12ZUser contributionsMediaWiki 1.24.1https://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11754GSOC2019TCPTestingAndAlignment2019-08-26T12:56:27Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.<br />
<br />
=== Week 11 ===<br />
<br />
* Found a bug related to timeout in ns-3. In ns-3, only for the first partial ACK RTO is reset. So if there is a scenario where TCP sender receives multiple partial ACKs, ns-3 will reset RTO only for first partial ACK and there is a possibility of a timeout. After fixing this bug, our validation results for Linux Reno became more overlapping. Following is the overlapping cwnd graph for Linux Reno after the bug fix. <br /> [[File:Dce-linux-reno-vs-ns3-linux-reno.png|550px]]<br />
* Fixed all the PRR related issues and validated Linux PRR using ns-3 DCE. cwnd traces of ns-3 Linux PRR was validated against the cwnd traces of DCE Linux PRR and following cwnd graph was obtained. <br /> [[File:Dce-linux-prr-vs-ns3-linux-prr.png|550px]]<br />
* Worked more PRR related issues.<br />
* Completed the documentation Linux PRR.<br />
* Started working on the alignment of ns-3 TCP CUBIC with Linux<br />
<br />
=== Week 12 ===<br />
<br />
* Created a final patch for Linux PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest]<br />
* Following results were obtained for the validation of ns-3 TCP CUBIC against Linux CUBIC using ns-3 DCE. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment/wikis/TCP-CUBIC-Validation-Results]<br />
* Following cwnd graph was obtained after aligning the observed differences. <br /> [[File:Dce-cubic-vs-linux-cubic.png|550px]]<br />
* Changing the default value of beta and setting the delayed acknowledgment to 2 segments gave better results.<br />
* Tried changing the packet size to 1500 bytes but with ns-3 stack on the receiver side, Linux stack sends the packet of 578 bytes only. And with Linux stack on the receiver side, Linux sender dynamically sets the delayed acknowledgment.<br />
<br />
=== Week 13 ===<br />
<br />
* Improve documentation<br />
* Code review from mentors<br />
* Prepare a final report<br />
<br />
<br />
= GSoC Project Summary =<br />
<br />
== Deliverables ==<br />
<br />
=== Link to Phase 1 tasks ===<br />
Implementation and Testing of Linux Reno in ns-3: https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxRenoMergeRequest<br />
<br />
=== Link to Phase 2 tasks ===<br />
Implementation and Testing of Linux PRR in ns-3: https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest<br />
<br />
=== Link to Phase 3 tasks ===<br />
Testing and Aligning ns-3 CUBIC with Linux: https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment<br />
<br />
=== Link to GSoC Summary Page ===<br />
https://ns-3-tcp-validation.github.io/</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11753GSOC2019TCPTestingAndAlignment2019-08-26T12:55:53Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.<br />
<br />
=== Week 11 ===<br />
<br />
* Found a bug related to timeout in ns-3. In ns-3, only for the first partial ACK RTO is reset. So if there is a scenario where TCP sender receives multiple partial ACKs, ns-3 will reset RTO only for first partial ACK and there is a possibility of a timeout. After fixing this bug, our validation results for Linux Reno became more overlapping. Following is the overlapping cwnd graph for Linux Reno after the bug fix. <br /> [[File:Dce-linux-reno-vs-ns3-linux-reno.png|550px]]<br />
* Fixed all the PRR related issues and validated Linux PRR using ns-3 DCE. cwnd traces of ns-3 Linux PRR was validated against the cwnd traces of DCE Linux PRR and following cwnd graph was obtained. <br /> [[File:Dce-linux-prr-vs-ns3-linux-prr.png|550px]]<br />
* Worked more PRR related issues.<br />
* Completed the documentation Linux PRR.<br />
* Started working on the alignment of ns-3 TCP CUBIC with Linux<br />
<br />
=== Week 12 ===<br />
<br />
* Created a final patch for Linux PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest]<br />
* Following results were obtained for the validation of ns-3 TCP CUBIC against Linux CUBIC using ns-3 DCE. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment/wikis/TCP-CUBIC-Validation-Results]<br />
* Following cwnd graph was obtained after aligning the observed differences. <br /> [[File:Dce-cubic-vs-linux-cubic.png|550px]]<br />
* Changing the default value of beta and setting the delayed acknowledgment to 2 segments gave better results.<br />
* Tried changing the packet size to 1500 bytes but with ns-3 stack on the receiver side, Linux stack sends the packet of 578 bytes only. And with Linux stack on the receiver side, Linux sender dynamically sets the delayed acknowledgment.<br />
<br />
=== Week 13 ===<br />
<br />
* Improve documentation<br />
* Code review from mentors<br />
* Prepare a final report<br />
<br />
= GSoC Project Summary =<br />
<br />
== Deliverables ==<br />
<br />
=== Link to Phase 1 tasks ===<br />
Implementation and Testing of Linux Reno in ns-3: https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxRenoMergeRequest<br />
<br />
=== Link to Phase 2 tasks ===<br />
Implementation and Testing of Linux PRR in ns-3: https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest<br />
<br />
=== Link to Phase 3 tasks ===<br />
Testing and Aligning ns-3 CUBIC with Linux: https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment<br />
<br />
=== Link to GSoC Summary Page ===<br />
https://ns-3-tcp-validation.github.io/</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11752GSOC2019TCPTestingAndAlignment2019-08-26T12:51:02Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.<br />
<br />
=== Week 11 ===<br />
<br />
* Found a bug related to timeout in ns-3. In ns-3, only for the first partial ACK RTO is reset. So if there is a scenario where TCP sender receives multiple partial ACKs, ns-3 will reset RTO only for first partial ACK and there is a possibility of a timeout. After fixing this bug, our validation results for Linux Reno became more overlapping. Following is the overlapping cwnd graph for Linux Reno after the bug fix. <br /> [[File:Dce-linux-reno-vs-ns3-linux-reno.png|550px]]<br />
* Fixed all the PRR related issues and validated Linux PRR using ns-3 DCE. cwnd traces of ns-3 Linux PRR was validated against the cwnd traces of DCE Linux PRR and following cwnd graph was obtained. <br /> [[File:Dce-linux-prr-vs-ns3-linux-prr.png|550px]]<br />
* Worked more PRR related issues.<br />
* Completed the documentation Linux PRR.<br />
* Started working on the alignment of ns-3 TCP CUBIC with Linux<br />
<br />
=== Week 12 ===<br />
<br />
* Created a final patch for Linux PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest]<br />
* Following results were obtained for the validation of ns-3 TCP CUBIC against Linux CUBIC using ns-3 DCE. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment/wikis/TCP-CUBIC-Validation-Results]<br />
* Following cwnd graph was obtained after aligning the observed differences. <br /> [[File:Dce-cubic-vs-linux-cubic.png|550px]]<br />
* Changing the default value of beta and setting the delayed acknowledgment to 2 segments gave better results.<br />
* Tried changing the packet size to 1500 bytes but with ns-3 stack on the receiver side, Linux stack sends the packet of 578 bytes only. And with Linux stack on the receiver side, Linux sender dynamically sets the delayed acknowledgment.<br />
<br />
=== Week 13 ===<br />
<br />
* Improve documentation<br />
* Code review from mentors<br />
* Prepare a final report</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11745GSOC2019TCPTestingAndAlignment2019-08-25T21:28:30Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.<br />
<br />
=== Week 11 ===<br />
<br />
* Found a bug related to timeout in ns-3. In ns-3, only for the first partial ACK RTO is reset. So if there is a scenario where TCP sender receives multiple partial ACKs, ns-3 will reset RTO only for first partial ACK and there is a possibility of a timeout. After fixing this bug, our validation results for Linux Reno became more overlapping. Following is the overlapping cwnd graph for Linux Reno after the bug fix. <br /> [[File:Dce-linux-reno-vs-ns3-linux-reno.png|550px]]<br />
* Fixed all the PRR related issues and validated Linux PRR using ns-3 DCE. cwnd traces of ns-3 Linux PRR was validated against the cwnd traces of DCE Linux PRR and following cwnd graph was obtained. <br /> [[File:Dce-linux-prr-vs-ns3-linux-prr.png|550px]]<br />
* Worked more PRR related issues.<br />
* Completed the documentation Linux PRR.<br />
* Started working on the alignment of ns-3 TCP CUBIC with Linux<br />
<br />
=== Week 12 ===<br />
<br />
* Created a final patch for Linux PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest]<br />
* Following results were obtained for the validation of ns-3 TCP CUBIC against Linux CUBIC using ns-3 DCE. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment/wikis/TCP-CUBIC-Validation-Results]<br />
* Following cwnd graph was obtained after aligning the observed differences. <br /> [[File:Dce-cubic-vs-linux-cubic.png|550px]]<br />
* Changing the default value of beta and setting the delayed acknowledgment to 2 segments gave better results.<br />
* Tried changing the packet size to 1500 bytes but with ns-3 stack on the receiver side, Linux stack sends the packet of 578 bytes only. And with Linux stack on the receiver side, Linux sender dynamically sets the delayed acknowledgment.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=File:Dce-cubic-vs-linux-cubic.png&diff=11744File:Dce-cubic-vs-linux-cubic.png2019-08-25T21:27:35Z<p>ApoorvaBhargava: overlapping cwng graph for DCE CUBIC v/s ns-3 CUBIC</p>
<hr />
<div>overlapping cwng graph for DCE CUBIC v/s ns-3 CUBIC</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11743GSOC2019TCPTestingAndAlignment2019-08-25T21:23:06Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.<br />
<br />
=== Week 11 ===<br />
<br />
* Found a bug related to timeout in ns-3. In ns-3, only for the first partial ACK RTO is reset. So if there is a scenario where TCP sender receives multiple partial ACKs, ns-3 will reset RTO only for first partial ACK and there is a possibility of a timeout. After fixing this bug, our validation results for Linux Reno became more overlapping. Following is the overlapping cwnd graph for Linux Reno after the bug fix. <br /> [[File:Dce-linux-reno-vs-ns3-linux-reno.png|550px]]<br />
* Fixed all the PRR related issues and validated Linux PRR using ns-3 DCE. cwnd traces of ns-3 Linux PRR was validated against the cwnd traces of DCE Linux PRR and following cwnd graph was obtained. <br /> [[File:Dce-linux-prr-vs-ns3-linux-prr.png|550px]]<br />
* Worked more PRR related issues.<br />
* Completed the documentation Linux PRR.<br />
* Started working on the alignment of ns-3 TCP CUBIC with Linux<br />
<br />
=== Week 12 ===<br />
<br />
* Created a final patch for Linux PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/LinuxPRRMergeRequest]<br />
* Following results were obtained for the validation of ns-3 TCP CUBIC against Linux CUBIC using ns-3 DCE. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment/wikis/TCP-CUBIC-Validation-Results]<br />
* Changing the default value of beta and setting the delayed acknowledgment to 2 segments gave better results.<br />
* Tried changing the packet size to 1500 bytes but with ns-3 stack on the receiver side, Linux stack sends the packet of 578 bytes only. And with Linux stack on the receiver side, Linux sender dynamically sets the delayed acknowledgment.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11741GSOC2019TCPTestingAndAlignment2019-08-25T17:43:40Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.<br />
<br />
=== Week 11 ===<br />
<br />
* Found a bug related to timeout in ns-3. In ns-3, only for the first partial ACK RTO is reset. So if there is a scenario where TCP sender receives multiple partial ACKs, ns-3 will reset RTO only for first partial ACK and there is a possibility of a timeout. After fixing this bug, our validation results for Linux Reno became more overlapping. Following is the overlapping cwnd graph for Linux Reno after the bug fix. <br /> [[File:Dce-linux-reno-vs-ns3-linux-reno.png|550px]]<br />
* Fixed all the PRR related issues and validated Linux PRR using ns-3 DCE. cwnd traces of ns-3 Linux PRR was validated against the cwnd traces of DCE Linux PRR and following cwnd graph was obtained. <br /> [[File:Dce-linux-prr-vs-ns3-linux-prr.png|550px]]<br />
* Completed the documentation Linux PRR.<br />
* Started working on the alignment of ns-3 implementation of TCP CUBIC with Linux.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=File:Dce-linux-prr-vs-ns3-linux-prr.png&diff=11740File:Dce-linux-prr-vs-ns3-linux-prr.png2019-08-25T17:43:19Z<p>ApoorvaBhargava: overlapping cwnd graph for ns-3 Linux PRR v/s DCE Linux PRR</p>
<hr />
<div>overlapping cwnd graph for ns-3 Linux PRR v/s DCE Linux PRR</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=File:Dce-linux-reno-vs-ns3-linux-reno.png&diff=11736File:Dce-linux-reno-vs-ns3-linux-reno.png2019-08-25T07:50:20Z<p>ApoorvaBhargava: Overlapping cwnd graph for validation of Linux Reno after the bug fix</p>
<hr />
<div>Overlapping cwnd graph for validation of Linux Reno after the bug fix</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11725GSOC2019TCPTestingAndAlignment2019-08-15T16:44:56Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.<br />
<br />
=== Week 9 ===<br />
<br />
* Added documentation for the Linux Reno in tcp.rst file. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/src/internet/doc/tcp.rst]<br />
* Added example for the Linux Reno in examples/tcp directory. [https://gitlab.com/apoorvabhargava/ns-3-dev/blob/LinuxReno/examples/tcp/tcp-linux-reno.cc]<br />
* Created a new branch named "rate-sample-prr" which contains the rate sample code rebased to latest ns-3-dev and added Linux PRR code over it. [https://gitlab.com/apoorvabhargava/ns-3-dev/tree/rate-sample-prr] The reason for using rate sample code is that the current implementation of PRR uses lastSackedBytes for the calculation of m_prrDelivered variable. And it was observed that in some scenarios lastSackedBytes came out to be negative like on arrival of partial ACK. So using rate sample we can avoid negative values and make the calculation of m_prrDelivered variable more straightforward.<br />
<br />
=== Week 10 ===<br />
<br />
* Create a merge request for Linux Reno congestion model in ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/86]<br />
* Fixed some issues in Linux PRR: <br /> 1) Resolved the issue of extra retransmissions in ns-3 [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5af3ec507aab85883932a4d95f31b859b475e50a] which was already reported on ns-3-dev. [https://gitlab.com/nsnam/ns-3-dev/issues/69] <br /> 2) Also, there was a difference in the behavior of ns-3 and Linux on exiting the recovery state. Linux increases the congestion window after exiting the recovery state whereas ns-3 does not. Tried resolving this issue but more improvement is required in this fix.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11702GSOC2019TCPTestingAndAlignment2019-07-28T14:26:52Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.<br />
<br />
=== Week 7 ===<br />
<br />
* Implemented the unit cases to test the behavior of TcpLinuxReno in ns-3. The test case checked that the slow start and congestion avoidance behavior matches Linux behavior as follows: <br /> 1) in both slow start and congestion avoidance phases, presence or absence of delayed acks does not alter the window growth <br /> 2) in congestion avoidance phase, the arithmetic for counting the number of segments ACKed and deciding when to increment the congestion window (i.e. following the Linux function tcp_cong_avoid_ai()) is followed.<br />
* Tested the slow start and congestion avoidance phase with delayed ack count of 1 and 2.<br />
* Also, test the slow start and congestion avoidance phase with a smaller segment size i.e. 524 bytes and a larger segment size i.e 1500 bytes.<br />
<br />
=== Week 8 ===<br />
<br />
* Worked on the system testing and following configuration was decided for the system testing: <br /><br /> Topology: Dumbbell (One sender and one receiver) <br /> AQM at the router: FIFO queue disc and PIE queue disc <br /> Bottleneck link bandwidth: 1Mbps <br /> Edge link bandwidth: 10 Mbps <br /> Initial cwnd: 10 segments <br /> RTT: 10 to 100 ms <br /><br />But later it was decided with the mentors that for now we should hold the system testing and start testing other features of TCP like PRR, SACK, and CUBIC.<br />
* Merged two separate test suites for the slow start and congestion avoidance phase of Linux Reno into a single test suite. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fcbf619894befaacd9d1b82f43bf4168bea6d888]<br />
* Added comments to the source code. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/7105d7d22e49106399f6d0ce83123344cb5a7254]<br />
* Mentors helped me increasing the level of logging and commenting on the tests.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11687GSOC2019TCPTestingAndAlignment2019-07-12T01:17:20Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.<br />
<br />
=== Week 5 ===<br />
<br />
* Discussed with mentors the future plans for the project. It was decided that first unit testing and system testing of LinuxReno should be completed with proper documentation and create the merge request for the same. After LinuxReno is completed, the same should be done for LinuxPRR.<br />
* Updated the Google Doc containing the details of the unit tests and system tests. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Tested PRR in a SACK disabled scenario.<br />
<br />
=== Week 6 ===<br />
<br />
* Reported an issue related to extra retransmission on receiving a partial ACK. [https://gitlab.com/nsnam/ns-3-dev/issues/69]<br />
* Discussed and decided on the design of unit cases and system test with the mentors. I am working on the unit tests to test the following two conditions: <br /> - Growth in cwnd due to byte counting (rather than ACK counting) in slow start and congestion avoidance phase. <br /> - cwnd is maintained in segments in Linux, but in bytes in ns-3. And due to rounding the cwnd in ns-3, TCP New Reno in ns-3 is less aggressive than Linux.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11671GSOC2019TCPTestingAndAlignment2019-06-27T10:47:01Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.<br />
<br />
=== Week 3 ===<br />
* Did unit testing of the alignment of TcpLinuxPrrRecovery class with Linux implementation of PRR. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/1f9910a6d55e5ad68653ed98551c226d9553e357]<br />
* Added two test cases pipe > ssthresh and pipe < ssthresh for testing and also documented about these test cases. [https://docs.google.com/document/d/1XYcvw4F9ttdrmEdK6UxuSp3qD86YCIC6xrxBr1DgQpg/edit?usp=sharing]<br />
* Looked into the implementation of div_u64 () method of Linux and observed that it is an architecture base division operation. If the system supports 64bit architecture then normal division operation is performed otherwise if the system supports 32bit architecture then an optimized 64bit division is performed. And it was decided that implementation of this method in ns-3 is not required.<br />
* Fixed a few issues in the merge request that was submitted earlier. [https://gitlab.com/nsnam/ns-3-dev/merge_requests/69/commits]<br />
<br />
=== Week 4 ===<br />
* Completed the alignment of TcpLinuxPrrRecovery class with Linux.<br />
* Tested the alignment in the scenario where 20 packets are sent from sender to the receiver and 3rd, 5th, 6th, 7th and 8th packet are dropped.<br />
* Discussed with mentors the limitation in ns-3 to support the Linux variant.<br />
* Observed and fixed the following issue in the implementation of PRR: <br />In the scenario mentioned in point 2, it was observed that on receiving a partial ACK for 5th packet, 2 packets were getting ACKed (3rd and 4th packet) out of which one was already SACKed (4th packet). So in this case, the calculation of prr_delivered (total bytes delivered during recovery) should consider only 3rd packet and not the 4th packet as it was already counted in prr_delivered (on receiving dupack for the 3rd packet with SACK block for 4th packet). Due to this reason, I changed the data type of lastSackedBytes to int so that it can store a negative value and subtract the bytes which were already SACKed in the prr_delivered calculation.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11618GSOC2019TCPTestingAndAlignment2019-06-13T04:56:43Z<p>ApoorvaBhargava: /* Week 2 */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11617GSOC2019TCPTestingAndAlignment2019-06-13T04:55:45Z<p>ApoorvaBhargava: /* Weekly Progress */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.<br />
<br />
=== Week 2 ===<br />
* Implemented a new class for Linux like PRR implementation. [https://gitlab.com/apoorvabhargava/ns-3-dev/commit/fa616a90e0f8651364fcb8be6fcb367b4946f10c]<br />
* Validated the implementation in a scenario of bulk traffic and updated the result in [https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit google doc]. Following is the overlapping graph obtained for cwnd obtained in bulk traffic scenario: <br /> [[File:CwndA.png|550px]]<br />
* Created a new repo which contains examples, patches and scripts. [https://gitlab.com/apoorvabhargava/tcp_testing_and_alignment?nav_source=navbar]<br />
* Decided with mentors the following test scenarios for PRR:<br />
- pipe < ssthresh<br />
- pipe > ssthresh<br />
And improved the document by <br />
* Tested default initial congestion window of 10 segments with existing test cases and 2 tests failed and 1 test crashed.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=File:CwndA.png&diff=11616File:CwndA.png2019-06-13T04:48:13Z<p>ApoorvaBhargava: Overlapping cwnd graphs for testing TcpLinuxPrrRecovery in bulk traffic scenario.</p>
<hr />
<div>Overlapping cwnd graphs for testing TcpLinuxPrrRecovery in bulk traffic scenario.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11607GSOC2019TCPTestingAndAlignment2019-06-03T18:38:35Z<p>ApoorvaBhargava: /* Community Bonding Period */</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3.[https://gitlab.com/nsnam/ns-3-dev/commit/6032126bf08f59e9bd1fc7a43029362ed63cb8c5]<br />
* Added the code for new TCP variant called TcpLinuxReno which contains the Linux like implementation of TCP New Reno. This work was done before the GSoC was started.[https://gitlab.com/apoorvabhargava/ns-3-dev/commit/5fa0225b1afe6733e749b61354ff9b8e5e1b21d5]<br />
* Next feature which I took for the alignment is Proportional Rate Reduction (PRR) for TCP. While checking the alignment of PRR in ns-3 with Linux, I observed an issue related to the handling of SACK blocks in PRR algorithm. I have reported this issue.[https://gitlab.com/nsnam/ns-3-dev/issues/59]<br />
<br />
=== Week 1 ===<br />
* Submitted merge request for the issue of handling SACK blocks with PRR algorithm.[https://gitlab.com/nsnam/ns-3-dev/merge_requests/69]. <br />
* Tested PRR in a single packet loss scenario using ns-3 DCE and aligned the observed differences. The difference was there because ns-3 handles everything in terms of bytes whereas Linux in terms of packets. According to RFC 6937, PRR calculates a variable called "sndcnt", which indicates exactly how many bytes should be sent in response to each ACK. The following equation is used to calculate the ''sndcnt'' in ns-3:<br /><br /><code>sendCount = std::ceil (m_prrDelivered * tcb->m_ssThresh * 1.0 / m_recoveryFlightSize) - m_prrOut;</code><br /><br /> Since ns-3 handles it in terms of bytes, the above equation was not giving the value of ''senCount'' in multiple of segment size which was not the case with Linux as it calculated the value of sndcnt in terms of packets.<br />
<br />
* Also, Documented the results.[https://docs.google.com/document/d/1yl9WKFCC40YznC0bbS3wRGHcWvkdqQLPO2sH_if3Ql8/edit?usp=sharing] Another difference was observed that on exiting the recovery phase ns-3 and Linux handles the updation of cwnd differently.<br />
* Had a discussion with mentors on how to handle differences between Linux and pure RFC standards. And it was discussed that ns-3 should have both the implementations but the default should be set as Linux as this will give more realistic results to the users.<br />
* It was finalized with mentors to have a Linux like PRR implementation in ns-3 as a separate class.</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11581GSOC2019TCPTestingAndAlignment2019-05-23T11:39:26Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux<br />
* Validate the alignment of SACK, DSACK, and RACK using ns-3 DCE<br />
* Align ns-3 implementation of Paced Chirping with Linux<br />
* Validate the alignment of Paced Chirping using ns-3 DCE<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions<br />
* Setting up a git repository for the project<br />
* Get suggestions on the testing scenarios which will be used for the validation<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux<br />
* Document the differences observed in ECN code of ns-3 and Linux<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux<br />
* Document the differences observed<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux<br />
* Document the differences observed<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux<br />
* Document the differences<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches<br />
<br />
= Weekly Progress =<br />
<br />
=== Community Bonding Period ===<br />
* Communicate with the mentors through call<br />
* Set up my git repository<br />
* Reported a bug by creating a merge request and it got merged into mainline of ns-3</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11542GSOC2019TCPTestingAndAlignment2019-05-14T09:02:12Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework that allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] during my first year of postgraduation. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution (DCE) framework.<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have a Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and proper documentation of all the differences will be provided. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC period is be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux.<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux.<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE.<br />
* Validate the alignment of DCTCP in data centre topology using ns3-DCE.<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux.<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux.<br />
* Validate the alignment of SACK, DSACK and RACK using ns-3 DCE.<br />
* Align ns-3 implementation of Paced Chirping with Linux.<br />
* Validate the alignment of Paced Chirping using ns-3 DCE.<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions.<br />
* Setting up a git repository for the project.<br />
* Get suggestions on the testing scenarios which will be used for the validation.<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux.<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux.<br />
* Document the differences observed in ECN code of ns-3 and Linux.<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE.<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE.<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux.<br />
* Document the differences observed.<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE.<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux.<br />
* Document the differences observed.<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE.<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux.<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE.<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux.<br />
* Document the differences.<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE.<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches.<br />
<br />
= Weekly Progress =</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11541GSOC2019TCPTestingAndAlignment2019-05-13T18:23:54Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework which allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] in my first year of postgraduate. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution framework (DCE).<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and provide the proper documentation of all the differences. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC will be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux.<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux.<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE.<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE.<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux.<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux.<br />
* Validate the alignment of SACK, DSACK and RACK using ns-3 DCE.<br />
* Align ns-3 implementation of Paced Chirping with Linux.<br />
* Validate the alignment of Paced Chirping using ns-3 DCE.<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period (6 May - 26 May 2019) ===<br />
* Contact the mentors and update weekly plan according to their suggestions.<br />
* Setting up a git repository for the project.<br />
* Get suggestions on the testing scenarios which will be used for the validation.<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux.<br />
<br />
=== Week 1 (27 May - 2 June 2019) ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux.<br />
* Document the differences observed in ECN code of ns-3 and Linux.<br />
<br />
=== Week 2 (3 June - 9 June 2019 ) ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE.<br />
<br />
=== Week 3 (10 June - 16 June 2019) ===<br />
* Validate Data Center TCP in data center topology using DCE.<br />
<br />
=== Week 4 (17 June - 23 June 2019) ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux.<br />
* Document the differences observed.<br />
<br />
=== Week 5 (24 June - 30 June 2019) ===<br />
* Align the differences found in SACK and validate the implementation using DCE.<br />
<br />
=== Week 6 (1 July - 7 July 2019) ===<br />
* Study the codebase of DSACK in ns-3 and Linux.<br />
* Document the differences observed.<br />
<br />
=== Week 7 (8 July - 14 July 2019) ===<br />
* Align the differences found in DSACK and validate the implementation using DCE.<br />
<br />
=== Week 8 (15 July - 21 July 2019) ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux.<br />
* Document the differences.<br />
<br />
=== Week 9 (22 July - 28 July 2019) ===<br />
* Align the differences found in RACK and validate the implementation using DCE.<br />
<br />
=== Week 10 (29 July - 4 August 2019) ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux.<br />
* Document the differences.<br />
<br />
=== Week 11 (5 August - 11 August 2019) ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE.<br />
<br />
=== Week 12 (13 August - 19 August 2019) ===<br />
* Submit all the required patches.<br />
<br />
= Weekly Progress =</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11533GSOC2019TCPTestingAndAlignment2019-05-13T11:23:15Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' [mailto:apoorvabhargava13@gmail.com Apoorva Bhargava]<br />
* '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson], [mailto:jain.vivek.anand@gmail.com Vivek Jain]<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework which allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation Cautious Adaptive RED in ns-3] in my first year of postgraduate. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution framework (DCE).<br />
<br />
= Technical Approach =<br />
<br />
Many features of ns-3 TCP are aligned with RFCs but not with TCP implementation in Linux. The main goal of this project is to have Linux like TCP implementation in ns-3 and cover main components of TCP Prague i.e ECN, DCTCP, RACK and Paced Chirping. I have already done the alignment of Slow Start and Congestion Avoidance phase of ns-3 New Reno with Linux TCP Reno and validated it in simple dumbbell topology with one sender and one receiver using ns-3 DCE. Results can be found [https://github.com/apoorvabhargava/ns-3-dev-git/wiki here]. Currently, I am working on alignment of PRR recovery algorithm of ns-3 with Linux using ns-3 DCE as it is default recovery algorithm in Linux kernel. Further, I will work on the alignment of ECN followed by DCTCP, as DCTCP uses ECN feature of TCP in its algorithm. Next, I will cover the alignment of RACK which will also cover the alignment of SACK and DSACK as these two are the pre-requisites. Lastly, the alignment of Paced Chirping will be done. Validation of all the aligned features of ns-3 TCP will be done using ns-3 DCE and provide the proper documentation of all the differences. Also, if time permits I will try to align the ns-3 implementation of TCP Cubic and TCP BBR with Linux kernel.<br />
<br />
= Milestones and Deliverables =<br />
<br />
The entire GSoC will be divided into 2 phases and the deliverables at the end of each phase will be as follows:<br />
<br />
=== Phase 1: ===<br />
<br />
* Align Explicit Congestion Notification (ECN) implementation of ns-3 with Linux.<br />
* Align Data Center TCP (DCTCP) implementation of ns-3 with Linux.<br />
* Validate the alignment of ECN in dumbbell topology using ns-3 DCE.<br />
* Validate the alignment of DCTCP in data center topology using ns3-DCE.<br />
<br />
=== Phase 2: ===<br />
<br />
* Align ns-3 implementation of Selective Acknowledgement (SACK) and Duplicate Selective Acknowledgement with Linux.<br />
* Align ns-3 implementation of Recent Acknowledgement (RACK) with Linux.<br />
* Validate the alignment of SACK, DSACK and RACK using ns-3 DCE.<br />
* Align ns-3 implementation of Paced Chirping with Linux.<br />
* Validate the alignment of Paced Chirping using ns-3 DCE.<br />
<br />
= Weekly Plan =<br />
<br />
=== Community Bonding Period ===<br />
* Contact the mentors and update weekly plan according to their suggestions.<br />
* Setting up a git repository for the project.<br />
* Get suggestions on the testing scenarios which will be used for the validation.<br />
* Work on the alignment of PRR as it the default recovery algorithm in Linux.<br />
<br />
=== Week 1: ===<br />
* Start understanding the codebase of ECN in ns-3 as well as in Linux.<br />
* Document the differences observed in ECN code of ns-3 and Linux.<br />
<br />
=== Week 2: ===<br />
* Align the differences found in ECN and validate the implementation in dumbbell topology using DCE.<br />
<br />
=== Week 3: ===<br />
* Validate Data Center TCP in data center topology using DCE.<br />
<br />
=== Week 4: ===<br />
* Start understanding the codebase of SACK in ns-3 as well as Linux.<br />
* Document the differences observed.<br />
<br />
=== Week 5: ===<br />
* Align the differences found in SACK and validate the implementation using DCE.<br />
<br />
=== Week 6: ===<br />
* Study the codebase of DSACK in ns-3 and Linux.<br />
* Document the differences observed.<br />
<br />
=== Week 7: ===<br />
* Align the differences found in DSACK and validate the implementation using DCE.<br />
<br />
=== Week 8: ===<br />
* Study the codebase of RACK in ns-3 as well as in Linux.<br />
* Document the differences.<br />
<br />
=== Week 9: ===<br />
* Align the differences found in RACK and validate the implementation using DCE.<br />
<br />
=== Week 10: ===<br />
* Study the codebase of Paced Chirping in ns-3 as well as Linux.<br />
* Document the differences.<br />
<br />
=== Week 11: ===<br />
* Align the differences found in Paced Chirping and validate the implementation using DCE.<br />
<br />
=== Week 12: ===<br />
* Submit all the required patches.<br />
<br />
= Weekly Progress =</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11532GSOC2019TCPTestingAndAlignment2019-05-13T06:56:02Z<p>ApoorvaBhargava: </p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' Apoorva Bhargava<br />
* '''Mentors:''' Tom Henderson, Vivek Jain<br />
* '''Abstract:''' This project aims at aligning the ns-3 TCP with Linux kernel to have a more realistic implementation of TCP in ns-3 with proper documentation of the differences. The features of TCP which will be aligned are ECN, RACK, SACK, DSACK, and Paced Chirping. To achieve this, ns-3 DCE (Direct Code Execution) will be used. DCE (Direct Code Execution) is a framework which allows the users to run kernel space protocol inside the ns-3 without changing the source code.<br />
* '''Code:''' to be added<br />
* '''About Me:''' I am a 2nd-year postgraduate student at National Institute of Technology, Karnataka India. I have worked on [https://github.com/apoorvabhargava/Implementation-of-TCP-Jersey-in-ns-3 Implementation of TCP Jersey in ns-3] and [https://github.com/apoorvabhargava/Implementation-of-CARED-in-ns-3 Implementation CARED AQM in ns-3] in my first year of postgraduate. Currently, I am working on Alignment and Validation of ns-3 TCP with Linux TCP using ns-3 Direct Code Execution framework (DCE).</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=GSOC2019TCPTestingAndAlignment&diff=11531GSOC2019TCPTestingAndAlignment2019-05-13T04:58:31Z<p>ApoorvaBhargava: Created page with "{{TOC}} = Project Overview = * '''Project Name:''' TCP Testing and Alignment * '''Student:''' Apoorva Bhargava * '''Mentors:''' Tom Henderson, Vivek Jain"</p>
<hr />
<div>{{TOC}}<br />
<br />
= Project Overview =<br />
<br />
* '''Project Name:''' TCP Testing and Alignment<br />
* '''Student:''' Apoorva Bhargava<br />
* '''Mentors:''' Tom Henderson, Vivek Jain</div>ApoorvaBhargavahttps://www.nsnam.org/mediawiki/index.php?title=Summer_Projects&diff=11530Summer Projects2019-05-13T04:50:14Z<p>ApoorvaBhargava: /* Google Summer of Code 2019 */</p>
<hr />
<div>{{TOC}}<br />
<br />
The project coordinates a few summer coding programs in which student developers are paired with mentors to produce code over the summer.<br />
<br />
= Google Summer of Code 2019 =<br />
<br />
ns-3 has been selected to participate in Google Summer of Code 2019 with four projects:<br />
<br />
* Apoorva Bhargava, [[GSOC2019TCPTestingAndAlignment | Testing and Alignment of ns-3 TCP with Linux TCP]]<br />
* Mishal Shah, [[GSOC2019AppStore | Improving the ns-3 AppStore and linking with bake]]<br />
* Tommaso Zugno, Integration of the 3GPP TR 38.901 channel model in the ns-3 spectrum module<br />
* Liangcheng Yu, Framework of Studying Flow Completion Time Minimization for Data Center Networks in ns-3 <br />
<br />
Below are project ideas and the 2019 student guide:<br />
<br />
* [[GSOC2019StudentGuide | ns-3 GSoC student guide]]<br />
* [[GSOC2019Projects | Project Ideas Page]]<br />
<br />
= European Space Agency Summer of Code in Space (SOCIS) 2019 =<br />
<br />
ns-3 projects have been included in the 2019 edition of ESA Summer of Code in Space<br />
<br />
* [[SOCIS2019 | ns-3 SOCIS student guide]]<br />
<br />
= Google Summer of Code 2018 =<br />
<br />
ns-3 participated in the 2018 edition of Google Summer of Code, with five students:<br />
<br />
* WenYing Dai, [[GSOC2018AccECN_ECN++ | Implementation of AccECN and ECN++ in ns-3]]<br />
* Muhammad Iqbal CR, [[GSOC2018Coexistence | Merging and Improvement of LTE and Wi-Fi Coexistence Module]]<br />
* Sourabh Jain, [[GSoC2018_DCE_Upgrade | Direct Code Execution upgrade]]<br />
* Davide Magrin, [[GSoC2018:_A_Simulation_Execution_Manager_for_ns-3 | A simulation execution manager for ns-3]]<br />
* Jude Niroshan, [[GSoC2018:Trust-based_routing_protocols_framework | Trust-based routing protocols framework]]<br />
<br />
* [[GSOC2018Projects | Project Ideas Page]]<br />
* [[GSOC2018StudentGuide | Student Application Guide]]<br />
<br />
= European Space Agency Summer of Code in Space (SOCIS) 2017 =<br />
<br />
ns-3 has been accepted to the 2017 ESA Summer of Code in Space, with student Pasquale Imputato (mentored by Tommaso Pecorella). The project successfully completed in October 2017 (details in the below wiki project page).<br />
<br />
* [[SOCIS2017 | project page]]<br />
* [https://codereview.appspot.com/330220043/ Final code review]<br />
<br />
The original project ideas page is posted below.<br />
<br />
* [[SOCIS2017Projects#Project_Ideas | Project Ideas page]]<br />
<br />
= Google Summer of Code 2017 =<br />
<br />
ns-3 was fortunate to mentor five outstanding students for the 2017 edition of [https://developers.google.com/open-source/gsoc/ Google Summer of Code].<br />
<br />
* [[GSOC2017AcceptedProjects | Accepted Projects]]<br />
== Final reports ==<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-August/013916.html ns-3 App Store] by Abhijith Anilkumar<br />
* [https://www.nsnam.org/wiki/GSOC2017Lte#Project_summary Enabling LTE CA handover to secondary cell] by Alexander Krotov<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013929.html TCP Prague] by Shravya Ks<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013918.html LTE and IPv6 support] by Manoj Kumar Rana<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-September/013921.html TBF and HHF] by Surya Seetharaman<br />
<br />
== Phase 2 reports ==<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014038.html BCube and FatTree topology helpers (component of TCP Prague project)]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014054.html Implementation of TBF and HHF]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014047.html Enabling LTE CA handover to secondary cell, Phase 2]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014042.html ns-3 App Store]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-July/014049.html Mobile IPv6 implementation with LTE support (report)]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-August/014058.html Mobile IPv6 implementation with LTE support (review request)]<br />
== Phase 1 reports ==<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013980.html Data Center TCP (component of TCP Prague project)]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013982.html Implementation of TBF and HHF traffic control]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013983.html Enabling LTE CA handover to secondary cell, Phase 1]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013985.html ns-3 App Store]<br />
* [http://mailman.isi.edu/pipermail/ns-developers/2017-June/013987.html Mobile IPv6 implementation with LTE support]<br />
== Background ==<br />
Below is some information that was used during the application phase.<br />
<br />
* [[GSOC2017Projects | Project Ideas Page]]<br />
* [[GSOC2017StudentGuide | Student Application Guide]]<br />
<br />
= European Space Agency Summer of Code in Space (SOCIS) 2016 =<br />
<br />
ns-3 had one student (Michael Di Perna) successfully complete the 2016 [http://sophia.estec.esa.int/socis/ ESA Summer of Code in Space]. <br />
<br />
* [[SOCIS2016 | Project page]] for Optical Satellite Systems project<br />
* [[SOCIS2016Projects#Project_Ideas | Project Ideas page]]<br />
<br />
= Mentored summer projects 2016 =<br />
<br />
ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis. Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.<br />
<br />
* See [[MentoredProjects2016]]<br />
<br />
= Google Summer of Code 2016 =<br />
<br />
ns-3 was not selected for the 2016 [https://developers.google.com/open-source/gsoc/ Google Summer of Code]. We mentored two summer projects outside of GSoC. Below were our materials prepared for our GSoC organizational application.<br />
* [[GSOC2016Projects | Project ideas page]]<br />
* [[GSOCStudentGuide | Student guide]]<br />
<br />
= Google Summer of Code 2015 =<br />
<br />
ns-3 was selected to participate in the 2015 [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code]. More information can be found on our Project Ideas page and our Student Guide.<br />
<br />
* [[GSOC2015AcceptedProjects | Accepted projects]]<br />
* [[GSOC2015Projects | Project ideas page]]<br />
* [[GSOC2015StudentGuide | Student guide]]<br />
<br />
This year's students were announced on April 27, and all four successfully completed the program:<br />
<br />
* Melchiorre Danilo Abrignani, [[GSOC2015LTECA | Carrier Aggregation support for the LTE module]]<br />
* Matthieu Coudron, [[GSOC2015MpTcpImplementation | Implementing multipath TCP (MPTCP) in ns3]]<br />
* Natale Patriciello, [[GSOC2015TCPTest | TCP layer refactoring with automated test on RFC compliance and validation]]<br />
* Vishwesh Rege, [[GSOC2015LrWpanMac | 802.15.4 realistic MAC and Energy Model]]<br />
<br />
= European Space Agency Summer of Code in Space (SOCIS) 2015 =<br />
<br />
ns-3 has been accepted to the 2015 [http://sophia.estec.esa.int/socis2015/ ESA Summer of Code in Space]. The ns-3 project had one student in SOCIS in each of 2013, 2014 and 2015. However, the satellite channel models project for 2015 [[SOCIS2015 | Satellite channel models]] did not successfully complete.<br />
<br />
* [[SOCIS2015Projects | Project ideas page]] (for reference)<br />
<br />
= Mentored summer projects =<br />
<br />
ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis. Students interested in this option should review the GSoC or SOCIS ideas page, or propose their own.<br />
<br />
We have one such mentored project in 2015:<br />
<br />
* Saswat Mishra, [[NeighborDiscoveryProject | Neighbor Discovery enhancements]]<br />
<br />
= Past summer projects =<br />
<br />
* [[GSOC2014AcceptedProjects | GSoC 2014 Accepted Projects]]<br />
* [[SOCIS2014TCP | SOCIS 2014 Accepted Project]]<br />
* [[MentoredProjects2014 | 2014 Mentored Projects]]<br />
* [[SOCIS2013BundleProtocolProject | SOCIS 2013 Accepted Project]]<br />
* [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br />
* [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br />
* [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br />
* [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br />
* [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]<br />
* [https://developers.google.com/open-source/soc/2008/?csw=1#ns3 GSoC 2008 Accepted Projects]</div>ApoorvaBhargava