Difference between revisions of "ECN support for qdiscs in ns-3"

From Nsnam
Jump to: navigation, search
Line 3: Line 3:
 
* '''Student:''' [mailto:shravya.ks0@gmail.com Shravya Kaudki Srinivas]
 
* '''Student:''' [mailto:shravya.ks0@gmail.com Shravya Kaudki Srinivas]
 
* '''Mentors:''' [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani] , [mailto:tomh@tomh.org Tom Henderson]
 
* '''Mentors:''' [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani] , [mailto:tomh@tomh.org Tom Henderson]
* '''Abstract:''' ECN is the most widely deployed congestion signaling mechanism in the Internet, and its use cases in wireless and data center networks have been increasing. In this work, I plan to implement ECN in ns-3, enable its support in qdiscs (e.g., RED, CoDel) and write tests to verify its functionality.
+
* '''Abstract:''' Explicit Congestion Notification (RFC 3168) is a mechanism for Active Queue Management (AQM) to notify endpoints of congestion that may be developing in a bottleneck queue, without resorting to packet drops. In ns-3, the current queue disciplines (e.g., RED) only support packet drops but not an ECN mode of operation. In this work, I plan to implement ECN mechanism in ns-3, enable its support in QueueDiscs and write tests to verify its functionality.
 
* '''Reference:''' The Addition of Explicit Congestion Notification (ECN) to IP ([https://tools.ietf.org/html/rfc3168  RFC 3168])
 
* '''Reference:''' The Addition of Explicit Congestion Notification (ECN) to IP ([https://tools.ietf.org/html/rfc3168  RFC 3168])
 
* '''About me:'''  I am pursuing B.Tech in Computer Science from National Institute of Technology Karnataka, Surathkal, India. Currently, I am a Mitacs intern working under Dr. Ehab Elmallah on Wireless Underwater Sensor Networks at University of Alberta, Canada.
 
* '''About me:'''  I am pursuing B.Tech in Computer Science from National Institute of Technology Karnataka, Surathkal, India. Currently, I am a Mitacs intern working under Dr. Ehab Elmallah on Wireless Underwater Sensor Networks at University of Alberta, Canada.
Line 17: Line 17:
  
 
[1] [http://dl.acm.org/citation.cfm?id=2630782 Implementing explicit congestion notification in ns-3]
 
[1] [http://dl.acm.org/citation.cfm?id=2630782 Implementing explicit congestion notification in ns-3]
 +
 +
==Design assumptions and requirements==
 +
 +
# Current behavior and performance of RED queue should be unaffected by the addition of ECN, if ECN is not in use.
 +
# It should be possible to enable and disable ECN marking on a per-queue basis.
 +
# Statistics for packets marked should be kept, and should be separate from drop statistics.
 +
# A "Mark" trace source should be provided. It may or may not be appropriate to keep this in the QueueDisc base class, where a "Drop" trace source already exists, since marking may not be applicable to all QueueDiscs. (This item is an open issue)
 +
 +
==Implementation plan==
 +
 +
The overall implementation is planned for two phases. In the first phase, ECN marking capability will be provided to RED queue, and the capability will be unit tested by injecting packets directly to the queue disc, without the operation of TCP. In the second phase, TCP will be extended to support ECN, and the RED queue disc will be tested with TCP flows.
  
 
== Weekly plan ==
 
== Weekly plan ==

Revision as of 14:40, 30 July 2016

Project overview

  • Project: Enabling support for Explicit Congestion Notification (ECN) in ns-3 queue disciplines
  • Student: Shravya Kaudki Srinivas
  • Mentors: Mohit P. Tahiliani , Tom Henderson
  • Abstract: Explicit Congestion Notification (RFC 3168) is a mechanism for Active Queue Management (AQM) to notify endpoints of congestion that may be developing in a bottleneck queue, without resorting to packet drops. In ns-3, the current queue disciplines (e.g., RED) only support packet drops but not an ECN mode of operation. In this work, I plan to implement ECN mechanism in ns-3, enable its support in QueueDiscs and write tests to verify its functionality.
  • Reference: The Addition of Explicit Congestion Notification (ECN) to IP (RFC 3168)
  • About me: I am pursuing B.Tech in Computer Science from National Institute of Technology Karnataka, Surathkal, India. Currently, I am a Mitacs intern working under Dr. Ehab Elmallah on Wireless Underwater Sensor Networks at University of Alberta, Canada.

Overview of ECN

ECN uses two bits in the IP header: ECN Capable Transport (ECT bit) and Congestion Experienced (CE bit), and two bits in the TCP header: Congestion Window Reduced (CWR) and ECN Echo (ECE). ns-3-dev already provides an implementation of ECN bits in the IP and TCP headers along with necessary setters and getters.

Although there has been a previous attempt to implement ECN in ns-3 [1], the approach adopted was non-trivial because of the lack of traffic-control layer in ns-3. Recently, traffic-control layer has been merged in the mainline of ns-3 and I plan to use the same for implementing ECN.

[1] Implementing explicit congestion notification in ns-3

Design assumptions and requirements

  1. Current behavior and performance of RED queue should be unaffected by the addition of ECN, if ECN is not in use.
  2. It should be possible to enable and disable ECN marking on a per-queue basis.
  3. Statistics for packets marked should be kept, and should be separate from drop statistics.
  4. A "Mark" trace source should be provided. It may or may not be appropriate to keep this in the QueueDisc base class, where a "Drop" trace source already exists, since marking may not be applicable to all QueueDiscs. (This item is an open issue)

Implementation plan

The overall implementation is planned for two phases. In the first phase, ECN marking capability will be provided to RED queue, and the capability will be unit tested by injecting packets directly to the queue disc, without the operation of TCP. In the second phase, TCP will be extended to support ECN, and the RED queue disc will be tested with TCP flows.

Weekly plan

Week 1

* Going through the RFC
* Going through the Linux and ns-2 stack 
* Preparing the architecture for merging ECN with the existing AQM mechanisms in ns-3

Key Deliverable: Information Architecture

Week 2

* Implementation of ECN bits in the TCP and IP headers
* Implementation of ECN Negotiation by adding ECN Capability to TCP's SYN/ACK packets 
* Writing tests for this scenario and documenting the ECN support in TCP and IP packets

Key Deliverable: RFC compliant packet structure

Week 3

* Implementation of ECN at TCP sender (i.e., setting ECN code points in data packets)
* Writing tests for this scenario and documentation of the implementation and tests. 

Key Deliverable: The sending module at layer 4

Week 4

* Incorporating ECN functionality in PIE 
* Write tests to  verify the functionality of ECN with PIE 
* Documenting the implementation of ECN for PIE.
* We can have Mid-term review this week

Key Deliverable : The complete implementation of ECN in PIE

Week 5

* Implementation of ECN at TCP receiver (i.e., recognising ECN marks from data packets)
* Writing example for implementation of ECN in layer 4
* Completing tests for this scenario and documenting the implementation and tests.

Key Deliverable: The complete implementation of ECN in layer 4

Week 6

* Integration across layers
* Verifying the complete functionality of ECN
* Putting up code for review
* Complete the documentation

Week 7

Week 7:
* Addressing reviewer’s comments
* Solving bugs before declaring the code to be 'ready to merge' state.
* Finalize the documentation.

Key Deliverable : Finalize the code for merging

Weekly Progress

Week 1

After going through the existing tcp and ip model of ns-3 , here are the points I found out:

tcp-header.h and tcp-header.cc

The tcp header has last 2 bits reserved for ecn, i.e Ece|cwr is already present

SetFlag(int)-> This function is used to set m_flags variable of TCP header. The current documentation mention it to be working as only
a uint6_t variable as only 6 bits are in use, we will make use of the last two reserved bits for ECN. Since the function is already
 implemented we will call this with modified parameter.

For example: The negotiation step of ECN Enable TCP connection will be 
Sender to Receiver -> SetFlag(TcpHeader::SYN | TcpHeader::ECE | TcpHeader::CWR)
Receiver to Sender -> SetFlag(TcpHeader::SYN | TcpHeader::ECE | TcpHeader::ACK)
Sender to Receiver -> SetFlag(TcpHeader::ACK)

ipv4-header.h and ipv4-header.cc

Ipv4 header also has the ECNtype enum with all 4 ecn codepoints  defined and also the setter(SetEcn()) and getter(GetEcn()) functions 
to set ECN values in m_tos and retrieve it. These functions haven’t been used in the implementation of any modules. We will use these 
setter and getter function for the  ECN manipulation in Ipv4.