1 / 25

Explicit Congestion Notification (ECN) RFC 3168

Justin Yackoski DEGAS Networking Group yackoski@cis.udel.edu CISC856 – TCP/IP Thanks to Namratha Hundigopal and Preethi Natarajan for slides. Explicit Congestion Notification (ECN) RFC 3168. Overview. The Problem – Congestion The other solution(s) TCP's basic congestion mechanisms

holloman
Download Presentation

Explicit Congestion Notification (ECN) RFC 3168

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. Justin Yackoski DEGAS Networking Group yackoski@cis.udel.edu CISC856 – TCP/IP Thanks to Namratha Hundigopal and Preethi Natarajan for slides Explicit Congestion Notification (ECN)RFC 3168

  2. Overview The Problem – Congestion The other solution(s) TCP's basic congestion mechanisms Active Queue Management Description of ECN How ECN works Why ECN is better Performance evaluation Status of ECN

  3. Congestion Router must buffer packets because input > output End-to-end delay increases as buffer fills When buffer is full, “tail drop” occurs

  4. TCP without ECN Congestion Detection Retransmit Timeout 3 duplicate ACKs “Congestion Avoidance” Happens after congestion has already occurred (Multiplicative decrease of cwnd AFTER loss) Current TCP does something like congestion ‘recovery’ Network is treated as a black box, no way to know of impending doom

  5. What can sometimes happen? Global Synchronization – many connections reduce sending rate at same time, channel is under-utilized Lock Out – queue space is monopolized by a few connections Full Buffers – If network is operating at capacity, buffers stay full No spare room for “bursts” of traffic End-to-end delay is increased due to queuing delays

  6. Active Queue Management Detect “incipient” (early) congestion Try to keep average queue size in “good” range Randomly choose IP-PDUs to notify about congestion (how?) max min Average queue size lies in-between the thresholds

  7. What always happens? Packet drops each time congestion is detected, very inefficient BAD for real-time applications

  8. Explicit Congestion Notification ECN is an AQM mechanism Routers notify TCP about incipient congestion Use TCP/IP headers to send ECN signals TCP treats ECN signals exactly the same as when a single dropped packet is detected BUT – Packets are NOT actually dropped

  9. ECN Bits in IP Header Value Name 00 Not-ECT (Not ECN Capable Transport) 10 ECT(0) (ECN Capable Transport (0) ) 01 ECT(1) (ECN Capable Transport(1) ) 11 CE (Congestion Experienced) 2 bits => 4 ECN Codepoints

  10. ECN Bits in TCP Header ECE flag - ECN-Echo flag CWR flag - Congestion Window Reduced flag

  11. Negotiation between TCP transport entities TCP Sender – sets both ECE and CWR in SYN TCP Receiver – sets only ECE in SYN-ACK A host must not set ECT in SYN or SYN-ACK Some faulty firewalls either drop an ECN-setup SYN packet or respond with an RST TCP-PDU sender receiver ECN-setup SYN ECN-setup SYN-ACK ACK

  12. Typical sequence of events(1) ECT is set in IP-PDU’s carrying data transmitted by the sender to indicate that ECN is supported by transport entities for this PDU ECN Negotiated during connection establishment ECT set • ECN enabled sender ECN enabled receiver ECN enabled router

  13. ECN-capable router detects incipient congestion, and sees that ECT is set in the IP-PDU The router sets CE in the IP-PDU Typical sequence of events(2) Incipient Congestion, set CE ECT set CE set thmax thmin

  14. ECN enabled receiver receives the IP-PDU with CE set. Receiver conveys the congestion information to the transport sender by setting ECE in the ACK TCP-PDU Typical sequence of events(3) Congestion!!! Let me inform the sender CE set ECN enabled sender ECE set in ACK ECN enabled receiver

  15. TCP sender receives the TCP-PDU with ECE set Sender becomes aware of incipient congestion in network Sender reacts as if a TCP-PDU was dropped (sender’s cwnd reduced). Typical sequence of events(4) Incipient Congestion, reduce cwnd ECE set ACK • ECN enabled sender ECN enabled receiver

  16. TCP sender sets CWR in the next new TCP-PDU to the receiver Indicates that the sender has reacted to congestion by reducing the cwnd Typical sequence of events(5) Incipient Congestion, reduce cwnd, Set CWR ECN enabled sender CWR set ECN enabled receiver

  17. Receiver stops sending ACKs with ECE set after getting a TCP-PDU with CWR set if there is no new congestion in the network Typical sequence of events(6) Sender has reduced cwnd, stop setting ECE flag ECE set ACK ECN enabled sender CWR set ECN enabled receiver ECN enabled router

  18. Rules of the Game - Sender • On receipt of ECE ACK packet, TCP sender SHOULD react in the same way as it would for a congestion loss in non-ECN-capable TCP • Sender TCP SHOULD NOT react more than once every RTT to the ECE ACK packet • Why? – We saw that receiver keeps sending ECE set ACKs until Receiver gets a TCP-PDU with CWR set from the sender • For CWR set TCP-PDU to reach the receiver and get acked takes at least 1 RTT. So any more ECEs received in this time span is for the same instance of congestion

  19. Rules of the Game - Sender • TCP sender should set CWR in the first new TCP-PDU the sender transmits after receiving an ECE set ACK • What if a CWR set TCP-PDU is lost? • Sender TCP detects the loss • The loss is treated as a new instance of congestion in network • Sender will have to again reduce its cwnd and retransmits the lost TCP-PDU without CWR set

  20. Rules of the Game - Receiver • To overcome dropped ECE ACK packets, receiver MUST keep sending ECE ACKs until it gets a TCP-PDU with CWR set • Any more IP-PDUs with CE set are treated as new instances of congestion in the network • In delayed ACKs, ECE in ACK is set if CE is set for any of the IP-PDUs being acknowledged • What does the receipt of CWR guarantee? • The sender received the ECE message ? • The sender reduced its congestion window ? NO YES

  21. Advantages of ECN • Prevents unnecessary packet drops at routers  less retransmissions  improvement in the “GOODPUT” • Avoids timeouts by getting faster notification to end hosts • Less retransmissions also means less traffic on the network

  22. ECN Performance Improvements • ECN+ - allow SYN ACKs to be marked • Internet draft currently • RED* - mark packets using ECN, don’t drop

  23. Is ECN Secure? • Does ECN add any insecurities to TCP and/or IP or make any problems worse? • Can a malicious router: • Interfere with handshake? • Falsely report congestion? • Fail to report congestion? • Disable ECN?

  24. Is ECN used? • Implemented in linux 2.4+, Solaris 9+, and Cisco routers since 12.2(8)T

  25. References RFC 3168 – ECN RFC 2309 – AQM A. Kuzmanovic. The Power of Explicit Congestion Notification. SIGCOMM ’05 A. Medina, M. Allman, and S. Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM CCR. 2005 http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_sample/sample.html http://www.icir.org/floyd/ecn.html http://www.icir.org/floyd/ecn/ecn_security.txt Slides from Namratha Hundigopal and Preethi Natarajan

More Related