1 / 25

Explicit Congestion Notification ECN

Explicit Congestion Notification ECN. Tilo Hamann Technical University Hamburg-Harburg, Germany. Outline. Motivation for ECN How ECN works Benefits of ECN New-ECN TCP Algorithm Simulation results Some numbers Conclusions. Motivation for ECN.

andrew
Download Presentation

Explicit Congestion Notification ECN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Explicit Congestion NotificationECN Tilo Hamann Technical University Hamburg-Harburg, Germany

  2. Outline • Motivation for ECN • How ECN works • Benefits of ECN • New-ECN TCP • Algorithm • Simulation results • Some numbers • Conclusions Tilo Hamannthamann@eecs.berkeley.edu

  3. Motivation for ECN • TCP relies on packets drops to detect congestion • usually caused by queue overflow at a gateway • many connections see packet drops • synchronization of loss • greater variance in queueing delay • Solution: active queue management (e.g. RED) • avoids synchronization of loss across multiple flows • tries to maintain a smaller average queue size • attempts to increase fairness • but packet drops are still the indication of congestion Tilo Hamannthamann@eecs.berkeley.edu

  4. Motivation for ECN • ECN uses “marked” instead of dropped packets for congestion indication • ECN can react to congestion before packets get lost • ECN avoids transmission delay due to unnecessary packet drops: • TCP sender does not need to wait for timeouts or duplicate ACKs • currently ECN is only defined for data packets • congestion in the ACK path is open for future research Tilo Hamannthamann@eecs.berkeley.edu

  5. How ECN works: TCP header • ECN makes use of four bits in the TCP header: • ECN Capable Transmission (ECT) bit: DS field, bit 6 • Congestion Experienced (CE) bit: DS field, bit 7(these two bits are currently listed unused in RFC2474 (DiffServ)) • ECN echo flag: reserved field, bit 9 • Congestion Window Reduced (CWR) flag: reserved field, bit 8 • Definitions: • ECT packet: a data packet of a ECN capable connection • CE packet: a marked ECT packet (ECT bit = 1, CE bit = 1) • ECN echo packet: an ACK with ECN echo flag set to 1 Tilo Hamannthamann@eecs.berkeley.edu

  6. How ECN works: connection setup • Connection setup phase: • TCP sender and receiver negotiate their ECN capability during connection setup • TCP sender sets the ECN echo flag and CWR in the SYN packet • TCP receiver sets, if also ECN capable, only the ECN echo flag in the SYN-ACK packet • If and only if both are ECN capable, the ECT bit gets set in every data packet Tilo Hamannthamann@eecs.berkeley.edu

  7. How ECN works: Gateway, TCP Receiver • If a ECT packet arrives at a RED gateway • it gets marked randomly (RED algorithm) if • the average queue size is greater than minth and • less than maxth • it gets always dropped if • average queue size is greater than maxth • the queue is full • After the receiver gets a CE packet, the ECN echo flag gets set in the next outgoing ACK • The receiver continues to set the echo bit until it receives a data packet with the CWR flag set Tilo Hamannthamann@eecs.berkeley.edu

  8. How ECN works: TCP sender • TCP should react to a ECN echo packet like it would to a lost packet: • cut the congestion window: cwnd_ = ½ ·cwnd_ • and reduce the slow start threshold • But TCP should not • increase cwnd_ for a ECN echo ACK • trigger an slow start in TCP-Tahoe • wait for roughly a half RTT in the fast recovery phase of TCP-Reno Tilo Hamannthamann@eecs.berkeley.edu

  9. How ECN works: TCP sender • TCP should react at most once per RTT to any congestion indication, including • timeout of the retransmit timer • duplicate ACKs • ECN echo ACK • TCP should set the CWR flag in the next outgoing packet after it has reduced its congestion window for any reason Tilo Hamannthamann@eecs.berkeley.edu

  10. Benefits of ECN • Benefits for short web transfers: • most of TCP loss recovery is expected to be with timeouts • worst case: first packet gets dropped • ECN reduces packets drops • Bulk data transfers • Real time flows (Non-TCP) Tilo Hamannthamann@eecs.berkeley.edu

  11. New-ECN • ECN-TCP is biased against connections with longer RTTs • Question: Can we use the marks to achieve a fair sharing of the available bandwidth? • Approach: • reduce window and • reduce the slope of the window-increase for each marked packet • increase window for each regular ACK and • increase slope every RTT while receiving regular ACKs Tilo Hamannthamann@eecs.berkeley.edu

  12. New-ECN: Algorithm • Regular ACK received: • increase window: • if ((First_Mark_Received_ = 1) && (Not_Increased_within_the_last_RTT)) {} • TCP initialization: • First_Mark_Received_ = 0 Tilo Hamannthamann@eecs.berkeley.edu

  13. New-ECN: Algorithm • Marked packet received: • First_Mark_Received_ = 1 • if (seqno_Ack_  recover_ ) { recover_ = maxseq_} Tilo Hamannthamann@eecs.berkeley.edu

  14. RED: pmax = 0.1 maxth = 20 minth = 10 wq = 0.002 Network topology: New-ECN: 1 = 0.9 2 = 0.9  = 16 tcpTick_ = 0.01 packet size: 512byte New-ECN: ns simulation parameters Tilo Hamannthamann@eecs.berkeley.edu

  15. Gateway Link 7: 10Mbps, 1ms Link 1: 10Mbps, 1ms  4ms Link 2: 10Mbps, 14ms  30ms Link 4: 10Mbps, 94ms  190ms Link 3: 10Mbps, 34ms  70ms 4 New-ECN connections (Test 10) Tilo Hamannthamann@eecs.berkeley.edu

  16. TCP4: 190ms TCP3: 70ms TCP2: 30ms TCP1: 4ms TCP4: 190ms TCP3: 70ms TCP2: 30ms TCP1: 4ms 4 New-ECN connections (Test 10) Tilo Hamannthamann@eecs.berkeley.edu

  17. New-ECN 70ms 4ms 30ms 190ms 4 New-ECN vs. 4 ECN connections (Test 7) Tilo Hamannthamann@eecs.berkeley.edu

  18. Gateway Link 7: 5Mbps, 1ms New-ECN Link 1: 10Mbps, 14ms  30ms ECN TCP-Friendliness (1) (Test 8) Tilo Hamannthamann@eecs.berkeley.edu

  19. 70ms 30ms 4ms New-ECN 4ms 30ms 70ms TCP-Friendliness (2) (Test 1) Tilo Hamannthamann@eecs.berkeley.edu

  20. 70ms 30ms 4ms New-ECN 4ms 30ms 70ms TCP-Friendliness (3) (Test 2) Tilo Hamannthamann@eecs.berkeley.edu

  21. 4ms 70ms 30ms 190ms 4ms 70ms 30ms 190ms 4 New-ECN connections (2) (Test 9) Tilo Hamannthamann@eecs.berkeley.edu

  22. 70ms 4ms 30ms 190ms 4ms 70ms 30ms 190ms 4 New-ECN connections (3) (Test 9) Tilo Hamannthamann@eecs.berkeley.edu

  23. 4 New-ECN TCP connections: Fairnessindex: TCP-Friendliness (Test 8): 4 ECN TCP connections: Fairnessindex: New-ECN: some numbers Tilo Hamannthamann@eecs.berkeley.edu

  24. New-ECN: some numbers (2) • seems to be proportional to RTT with 1<  <2 • where and •  is ranges over 1 to a few RTT t  Tilo Hamannthamann@eecs.berkeley.edu

  25. Conclusions • It is possible to achieve fairness by using the congestion feedback provided by ECN • New-ECN seems to be TCP friendly • Some potential problems: • How to choose the design parameters? • Interaction between TCP-Reno and New-ECN TCP • Future work: • multiple congested gateways • more congestion indication bits? • ECN Home-Page: • http://www.aciri.org/floyd/ecn.html Tilo Hamannthamann@eecs.berkeley.edu

More Related