GSOC2018AccECN ECN++

From Nsnam
Revision as of 08:43, 8 July 2018 by Wenying (Talk | contribs) (Week - 7 (June 25 - July 1))

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.
  • 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++ (https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-02)

AccECN (https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-06)

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 consist of the following two aspects: 1. whether it sets ECT 2. its response to congestion feedback

AccECN provides 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 needs to cooperate with other standards which defined the usage of the information such as regular ECN (RFC 3168), ECN+ (RFC 5562), ECN++. 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 feedback 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 (July 16 - July 22)

  • Test the basic workflow about AccECN

Week - 11 (July 23 - July 29)

  • 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 (July 30 - August 5)

  • Test ECN++ with AccECN feedback

Week - 13 (August 6 - August 14)

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

Weekly Progress

Week - 1 (May 14 - May 20)

  • setup the git repo with Classic ECN implementation and started the implementation of ECN++ from state and related variable extension
In tcp-socket-base.{h, cc}
define m_useEcnPp in TcpSocketBase class to mark if the client is ECN enabled or not
  • briefly studied the test cases written for the classic ECN and discussed with mentor about the possible test case
Test whether ECE/CWR flags are set correctly in TCP header
Test whether ECT bit(tos field) are set correctly in IP header 
Test whether congestion window are reduced correctly
  • planning to complete the implementation of ECN++ in all control packets in the next week

Week - 2 (May 21 - May 27)

  • set ECT in all control packet except SYN if ECN++ is enabled with classic ECN feedback
ECT is marked by invoking AddSocketTags method.
AddSocketTags mathod is only invoked by SendDataPacket method and SendEmptyPacket method. 
Always, it will invoke SendEmptyPacket with tcp flags to send control packet.

TcpSocketBase::AddSocketTags in tcp-socket-base.{h, cc} 
if (m_tcb->m_ecnState != TcpSocketState::ECN_DISABLED) {
    // Set ECT(0) if ECN is enabled
} else if(m_useEcnPp && ((flags & TcpHeader::SYN) == 0 || (flags & TcpHeader::ACK) == 1)) {
    // Set ECT(0) if ECN++ is enabled
    // ECT MUST NOT set in SYN packet for ECN++ with classic ECN feedback
} else {
    // Set the last received ipTos
}

Week - 3 (May 28 - June 3)

  • redefine an enum named EcnOps_t instead of m_useEcn and m_useEcnPp to make the state of ECN and ECN++ more clear
typedef enum {
    NoEcn = 0,  // ECN is not used
    ClassicEcn, // Classic ECN is used
    EcnPp,      // ECN++ is used to mark TCP control packets
} EcnOps_t;
  • implement the negotiation process for ECN++
For the receiver: the negotiation finished when the receiver received SYN packet, then ECN state will transfer
if it receives a SYN packet with [ECE|CWR] flags
    if the receiver is ECN enabled: send SYN/ACK with [ECE] flag first, then transfer into ECN_IDLE state
    if the receiver is ECN++ enabled: transfer into ECN_IDLE state, then send SYN/ACK with [ECE] flag
otherwise: send SYN/ACK, transfer into ECN_DISABLED state

For the sender: the negotiation finished when the sender received SYN/ACK packet, then ECN state will transfer
if it receives a SYN/ACK packet with[ECE] flags
    if the sender is ECN enabled: send ACK first, then transfer into ECN_IDLE state
    if the receiver is ECN++ enabled: transfer into ECN_IDLE state, then send ACK
otherwise: send ACK, transfer into ECN_DISABLED state

Week - 4 (June 4 - June 10)

  • prepare a google doc to discuss the congestion response for SYN/ACK in ECN++
  • implement congestion response for SYN/ACK packet in ECN++ based on RFC 5562 Fig.2.
if ECN-setup SYN/ACK, ECT suffer congestion and marked with CE:
    then the sender will send out ACK|ECE to feed back this congestion information
    when the receiver get this feedback information, then reduce IW to I SMSS and send out another ECN-setup SYN/ACK, No ECT 
  • Because of the merge about classic ECN code finished, a new repo nsnam/ns-3-dev-git build and the next work will on gsoc-next branch

Week - 5 (June 11 - June 17)

  • prepare a google doc to discuss the congestion response for pure ACKs in ECN++
  • implement congestion response for pure ACKs in ECN++
ECN++ enables setting ECT in pure ACKs packet with no data, 
so it is possible to receive a packet both with ECE bit in TCP header and CE bit in IP header.
Therefore, extend a new state named ECN_ECE_CE_RCVD in EcnState_t to support this situation.

Week - 6 (June 18 - June 24)

  • prepare a google doc to discuss the congestion response for W probe in ECN++
  • implement congestion response for W probe in ECN++
For congestion response in W probe packet, we should turn to ECN_ECE_RCVD and waiting until r_wnd open. 
When trying to  send out data packet, we do some congestion response at the same time

Week - 7 (June 25 - July 1)

  • prepare a google doc to discuss the congestion response for FIN/RST in ECN++ and implement it.
congestion response about FIN/RST in ECN++ is not required, 
it means should not detect CE in FIN/RST receiver, so no feedback and no congestion response.
  • prepare a google doc to discuss the congestion response for Re-XMT in ECN++ and implement it.
TCP sender will set ECT on re-transmitted segment.
The TCP data receiver MUST ignore the CE codepoint on incoming segments that fail any validity check.
If the TCP sender receives feedback that a retransmitted packet was CE-marked, 
  it will react as it would to any feedback of CE-marking on a data packet

Week - 8 (July 2 - July 8)

  • prepare a google doc to discuss the test case for ECN++
  • prepare the test code, example code and document for ECN++, testing and debugging ECN++ in ns-3
  • prepare the first patch for ECN++ to review