GSOC2018AccECN ECN++

From Nsnam
Revision as of 02:12, 10 May 2018 by Wenying (Talk | contribs) (Technical Approach)

Jump to: navigation, search

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

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

Return to GSoC 2018 Accepted Projects page.

Project overview

  • Project name: Implementation of AccECN and ECN++ in ns-3
  • Abstract: Reducing Internet Transport Latency is an interesting research topic and has gained significant attention in the recent past. Some of the promising new solutions rely on Explicit Congestion Notification (ECN) (RFC 3168) to notify TCP endpoints of congestion that may be developing in a bottleneck queue, without resorting to packet drops. As a result, there have been attempts at Internet Engineering Task Force (IETF) to extend the functionality of ECN and provide rich feedback to TCP endpoints. In this regard, Accurate ECN feedback (AccECN) and ECN++ are two active topics of discussion at IETF. This project proposal is to: extend the ECN implementation in ns-3 to support AccECN and ECN++, test the correctness of implementation and provide examples.
  • Code: TBD
  • About me: I am a first-year postgraduate student in Tsinghua University. My major is computer science focusing on the research about computer network architecture mainly in routing layer and transport layer. I have attended 2017 IETF in Singapore, so I am pretty interested in implementing an IETF RFC or draft hands-on.

Technical Approach

ECN++ is a sender-side change. The feedback behavior at the receiver depends on whether classic ECN feedback or experimental AccECN feedback has been negotiated. ECN++ allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.For each type of control packet or transmission, the detailed changes to the sender's behavior consists of the following two aspects: 1. whether it sets ECT 2. its response to congestion feedback


AccECN provide more Accurate ECN feedback in the TCP header to provide more than one feedback signal per RTT. This schema only defined how to feedback more information. AccECN need to cooperate with other standards which defined the usage about the information such as regular ECN(RFC 3168) , ECN+(RFC 5562). Therefore how to use AccECN feedback information to optimize the TCP performace is out of scope for AccECN implementation. The AccECN protocol was designed into two parts: 1. an essential part that re-uses TCP header bits to feed back the number of arriving CE marked packets. 2. the supplementary part using a new AccECN TCP option that provides additional feedback on the number of bytes that arrive marked with each of the three ECN codepoints(not just CE marks).

Milestones and Deliverables

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

Phase 1: Implement ECN++ with classic ECN feedback

  • state and related variable extension about implementing ECN++
  • extend packet send method to support ECN++ with classic ECN feedback, including SYN/ACK, pure ACK, Window prob, retransmission packet
  • implement congestionDetectionClassicECN method to detect whether encounter congestion when receiving packet with classic ECN feedback
  • implement congestion response to different packet types invoke congestionDetectionClassicECN

Phase 2: Implement basic workflow about AccECN

  • state and member variable extension to support AccECN implementation
  • tcp-header extension to support AccECN
  • define four AccECN counters(m_rcep, m_rceb, m_re0b, m_e1b) to support AccECN feedback which is used in packet header and option field setting
  • packet header setting and response before AccECN negotiation finished(packet do not contain the option field)
  • packet header setting and response after AccECN negotiation finished(packet do not contain the option field)
  • define a new tcp header option for AccECN
  • packet header setting and response before AccECN negotiation finished(packet contains the option field)
  • packet header setting and response after AccECN negotiation finished(packet contains the option field)

Phase 3: Implement ECN++ with AccECN feedback

  • extend SYN packet send method to support ECN++ with AccECN feedback
  • implement congestionDetectionAccECN method to detect whether encounter congestion when receiving packet with AccECN feedback
  • apply congestionDetectionAccECN method to trigger congestion response to different packet type

Weekly plan

Community bonding period (April 23 - May 14)

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

Week - 1 (May 14 - May 20)

  • state and related variable extension about implementing ECN++
  • test the basic workflow for ECN++ in noECN feedback mode

Week - 2 (May 21 - May 27)

  • extend packet send method to support ECN++ with classic ECN feedback, including SYN/ACK, pure ACK, Window prob, retransmission packet

Week - 3 (May 28 - June 3)

  • implement congestionDetectionClassicECN method to detect whether encounter congestion when receiving packet with classic ECN feedback
  • implement congestion response to different packet types invoke congestionDetectionClassicECN

Week - 4 (June 4 - June 10)

  • test basic ECN++ workflow in classicECN feedbackmode
  • Prepare for first mid term review

Week - 5 (June 11 - June 17)

  • state and member variable extension to support AccECN implementation
  • tcp-header extension to support AccECN
  • test tcp header extension for AccECN

Week - 6 (June 18 - June 24)

  • define four AccECN counters(m_rcep, m_rceb, m_re0b, m_e1b) to support AccECN feedback which is used in packet header and option field setting
  • provide of corresponding trace sources

Week - 7 (June 25 - July 1)

  • packet header setting and response before AccECN negotiation finished(packet do not contain the option field)
  • packet header setting and response after AccECN negotiation finished(packet do not contain the option field)

Week - 8 (July 2 - July 8)

  • test basic AccECN workflow with no AccECN option field
  • prepare for second mid term review

Week - 9 (July 9 - July 15)

  • define a new tcp header option for AccECN
  • test tcp header option field
  • packet header setting and response before AccECN negotiation finished(packet contains the option field)
  • packet header setting and response after AccECN negotiation finished(packet contains the option field)

Week - 10 (July16 - July22)

  • Test the basic workflow about AccECN

Week - 11 (July23 - July29)

  • extend SYN packet send method to support ECN++ with AccECN feedback
  • implement congestionDetectionAccECN method to detect whether encounter congestion when receiving packet with AccECN feedback
  • apply congestionDetectionAccECN method to trigger congestion response to different packet type

Week - 12 (July30 - August5)

  • Test ECN++ with AccECN feedback

Week - 13 (August6 - August14)

  • Provide example for the user ecnpp-accecn.cc
  • Bug fixes, final documentation and prepare the code to merge

Weekly Progress