ECN Series - Part 2


ECN (Explicit Congestion Notification) to function effectively, there must be coordination between both the TCP layer (transport layer) and the IP layer (network layer).

ECN bits in IP header

The ECN bits in the IP header can be broken down into key points for clarity:

  1. Location in IP Header: ECN utilizes two specific bits located in the Traffic Class field of the IPv6 header or the Differentiated Services (DS) field of the IPv4 header.


  2. ECN Field Composition: The two bits together are known as the ECN field. This field is used to convey information about the congestion status of the network.


  3. ECN Field Values:

  • 00: Indicates that the transport is not ECN-capable. This means that the packet cannot participate in ECN-based congestion notification.
  • 01 and 10: Both values indicate that the transport is ECN-capable, but no congestion has been encountered. These values are used to mark packets that can be part of ECN without signaling any detected congestion.
  • 11: Known as the Congestion Experienced (CE) codepoint. This value signals that congestion has been detected somewhere along the packet's path.

ECN bits in TCP header

In the TCP header, ECN utilizes two specific flags to facilitate congestion notification and response mechanisms. These flags are part of the TCP header's structure and are critical for implementing ECN in TCP-based communication. The two relevant ECN flags in the TCP header are:

  1. ECN-Echo (ECE) Flag:

  • The ECE flag is used by both the sender and the receiver to signal the presence of network congestion.
  • When a network device (like a router) detects impending congestion, it marks IP packets with the Congestion Experienced (CE) codepoint in the IP header. The receiver, upon receiving a packet marked with CE, sets the ECE flag in the TCP acknowledgment (ACK) it sends back to the sender. This notifies the sender that congestion was encountered along the path.
  • The sender, upon receiving an ACK with the ECE flag set, understands that its packets have experienced congestion. As a response, it reduces its transmission rate to alleviate the congestion. The sender also uses the ECE flag in subsequent packets to acknowledge that it has received the congestion notification.
  1. Congestion Window Reduced (CWR) Flag:

  • The CWR flag is used by the sender to indicate to the receiver that it has received the congestion notification (via the ECE flag) and has taken action to reduce its transmission rate by adjusting its congestion window.
  • This flag is a way for the sender to communicate that it has responded to the congestion signal, allowing the receiver to reset the ECE flag in future acknowledgments, as the sender has already acknowledged and reacted to the congestion.

ECN Negotiation in TCP:

  1. Initial Handshake Attempt by Sender:

    • The sender, if it is ECN-capable, will initially attempt to negotiate ECN usage by setting the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags in the SYN packet. This indicates to the receiver that the sender is capable of and wishes to use ECN for this connection.
  2. Receiver's Response:

    • If the receiver is ECN-capable and willing to use ECN, it will respond with a SYN-ACK packet with the ECE flag set, indicating its agreement to use ECN for the connection.
    • If the receiver is not ECN-capable or is configured not to use ECN, it will not set the ECE flag in the SYN-ACK response. This indicates to the sender that ECN should not be used for this connection.
  3. Sender's Reaction to Receiver's Capability:

    • Upon receiving the SYN-ACK from the receiver, the sender checks for the ECE flag. If the ECE flag is not set (indicating the receiver is not ECN-capable or unwilling to use ECN), the sender proceeds with the connection without setting the ECN field in the IP header for subsequent packets (i.e., it will not mark packets as ECN-capable with ECT codepoint 01 or 10).





    Comments

    Popular posts from this blog

    ECN Series - Part1