Explicit Congestion Notification ECN Tilo Hamann Technical University Hamburg-Harburg, Germany

Tilo Hamann Outline Motivation for ECN How ECN works Benefits of ECN New-ECN TCP –Algorithm –Simulation results –Some numbers Conclusions

Tilo Hamann 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 Hamann 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 Hamann 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 Hamann 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 Hamann 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 min th and less than max th –it gets always dropped if average queue size is greater than max th 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 Hamann 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 Hamann 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 Hamann 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 Hamann 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 ACK s New-ECN

Tilo Hamann 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 Hamann New-ECN: Algorithm Marked packet received: –First_Mark_Received_ = 1 –if (seqno_Ack_  recover_ ) { recover_ = maxseq_ }

Tilo Hamann New-ECN: ns simulation parameters RED: –p max = 0.1 –max th = 20 –min th = 10 –w q = Network topology: New-ECN: –  1 = 0.9 –  2 = 0.9 –  = 16 –tcpTick_ = 0.01 –packet size: 512byte

Tilo Hamann 4 New-ECN connections (Test 10) Link 1: 10Mbps, 1ms  4ms Link 2: 10Mbps, 14ms  30ms Link 4: 10Mbps, 94ms  190ms Link 3: 10Mbps, 34ms  70ms Gateway Link 7: 10Mbps, 1ms

Tilo Hamann 4 New-ECN connections (Test 10) TCP3: 70ms TCP4: 190ms TCP2: 30ms TCP1: 4ms TCP2: 30ms TCP3: 70ms TCP4: 190ms

Tilo Hamann 4 New-ECN vs. 4 ECN connections (Test 7) New-ECN 190ms 30ms 4ms 70ms

Tilo Hamann TCP-Friendliness (1) (Test 8) Link 1: 10Mbps, 14ms  30ms Gateway Link 7: 5Mbps, 1ms ECN New-ECN

Tilo Hamann TCP-Friendliness (2) (Test 1) New-ECN 30ms 70ms 4ms 30ms 4ms

Tilo Hamann TCP-Friendliness (3) (Test 2) New-ECN 30ms 70ms 4ms 30ms 4ms

Tilo Hamann 4 New-ECN connections (2) (Test 9) 70ms 30ms 190ms 4ms 30ms 70ms 4ms 190ms

Tilo Hamann 4 New-ECN connections (3) (Test 9) 70ms 30ms 190ms 4ms 30ms 70ms 4ms 190ms

Tilo Hamann New-ECN: some numbers 4 New-ECN TCP connections: –Fairnessindex: –TCP-Friendliness (Test 8): 4 ECN TCP connections: –Fairnessindex:

Tilo Hamann 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 Hamann 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: –