RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP

Network Working Group: K. Ramakrishnan (TeraOptic Networks), S. Floyd (ACIRI), D. Black (EMC)
Request for Comments: 3168
Updates: 2474, 2401, 793
Obsoletes: 2481
Category: Standards Track
Published: September 2001

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This memo specifies the incorporation of ECN (Explicit Congestion Notification) into TCP and IP, including ECN's use of two bits in the IP header.

Contents

• 1. Introduction
• 2. Conventions and Acronyms
• 3. Assumptions and General Principles
• 4. Active Queue Management (AQM)
• 5. Explicit Congestion Notification in IP
  • 5.1 ECN as an Indication of Persistent Congestion
  • 5.2 Dropped or Corrupted Packets
  • 5.3 Fragmentation
• 6. Support from the Transport Protocol
  • 6.1 TCP
  • 6.1.1 TCP Initialization
    • 6.1.1.1 Middlebox Issues
    • 6.1.1.2 Robust TCP Initialization with an Echoed Reserved Field
  • 6.1.2 The TCP Sender
  • 6.1.3 The TCP Receiver
  • 6.1.4 Congestion on the ACK-path
  • 6.1.5 Retransmitted TCP packets
  • 6.1.6 TCP Window Probes
• 7. Non-compliance by the End Nodes
• 8. Non-compliance in the Network
  • 8.1 Complications Introduced by Split Paths
• 9. Encapsulated Packets
  • 9.1 IP packets encapsulated in IP
    • 9.1.1 The Limited-functionality and Full-functionality Options
    • 9.1.2 Changes to the ECN Field within an IP Tunnel
  • 9.2 IPsec Tunnels
    • 9.2.1 Negotiation between Tunnel Endpoints
      • 9.2.1.1 ECN Tunnel Security Association Database Field
      • 9.2.1.2 ECN Tunnel Security Association Attribute
      • 9.2.1.3 Changes to IPsec Tunnel Header Processing
    • 9.2.2 Changes to the ECN Field within an IPsec Tunnel
    • 9.2.3 Comments for IPsec Support
  • 9.3 IP packets encapsulated in non-IP Packet Headers
• 10. Issues Raised by Monitoring and Policing Devices
• 11. Evaluations of ECN
  • 11.1 Related Work Evaluating ECN
  • 11.2 A Discussion of the ECN nonce
    • 11.2.1 The Incremental Deployment of ECT(1) in Routers
• 12. Summary of changes required in IP and TCP
• 13. Conclusions
• 14. Acknowledgements
• 15. References
• 16. Security Considerations
• 17. IPv4 Header Checksum Recalculation
• 18. Possible Changes to the ECN Field in the Network
  • 18.1 Possible Changes to the IP Header
    • 18.1.1 Erasing the Congestion Indication
    • 18.1.2 Falsely Reporting Congestion
    • 18.1.3 Disabling ECN-Capability
    • 18.1.4 Falsely Indicating ECN-Capability
  • 18.2 Information carried in the Transport Header
  • 18.3 Split Paths
• 19. Implications of Subverting End-to-End Congestion Control
  • 19.1 Implications for the Network and for Competing Flows
  • 19.2 Implications for the Subverted Flow
  • 19.3 Non-ECN-Based Methods of Subverting End-to-end Congestion Control
• 20. The Motivation for the ECT Codepoints
  • 20.1 The Motivation for an ECT Codepoint
  • 20.2 The Motivation for two ECT Codepoints
• 21. Why use Two Bits in the IP Header?
• 22. Historical Definitions for the IPv4 TOS Octet
• 23. IANA Considerations
  • 23.1 IPv4 TOS Byte and IPv6 Traffic Class Octet
  • 23.2 TCP Header Flags
  • 23.3 IPSEC Security Association Attributes
• 24. Authors' Addresses
• 25. Full Copyright Statement