This is part 5 of a 4-part series on the ToS field (i.e. Differentiated Services Field) of IP frames. 🙂 Yes, yes, it is the running joke in the office on how this 4-part blog actually has 5 parts. Heck, it’s a blog… who cares.
Make sure you have already read Part 1, Part 2, Part 3 and Part 4 of this blog.

Once again, I’ll pull in the WireShark capture from my first blog:


Notice the two ECN (Explicit Congestion Notification) bits above that are part of the Differentiated Services Field (i.e. ToS). They are the “Currently Unused” bits from RFC 2474 which was written in 1998 and discussed in blog 3.  Remember “currently unused (usually  🙂 )” heh heh heh, I slay me. Well, these two bits were defined in 2001 in RFC 3168.

These two ECN bits are used by hosts or routers (generally) to indicate possible congestion.

  • ECN-Capable Transport (ECT) = 10 or 01
  • Not-ECN-Capable Transport (Not-ECT) = 00
  • Congestion Experienced (CE) = 11NOTE: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.

Operation of ECN with TCP
Wikipedia just kicks butt at summarizing this topic so, I’m going to paste in a few paragraphs. Read this out loud slooooowly :

<<< begin paste >>>
In addition to the two ECN bits in the IP header, TCP uses two flags in the TCP header to signal the sender to reduce the amount of information it sends. These are the ECN-echo (ECE) and Congestion Window Reduced (CWR) bits explained below.

Use of ECN on a TCP connection is optional; for ECN to be used, it must be negotiated at connection establishment by including suitable options in the SYN and SYN-ACK segments. When ECN has been negotiated on a TCP connection, the sender marks all data segments with the ECN-capable codepoint. A router that detects impending congestion may choose to mark an ECN-capable packet with the congestion experienced codepoint rather than dropping it outright.

Upon receiving a TCP segment with the Congestion Experienced codepoint, the TCP receiver sends an acknowledgment with the ECN-echo flag set. The ECN-echo bit indicates congestion to the sender, which reduces its congestion window as for a packet drop. It then acknowledges the congestion indication by sending a segment with the Congestion Window Reduced codepoint.
<<< end paste >>>

I think you get the picture. Read the RFC if you are drooling to learn more. Imagine, they used bits that were reserved back in 1981. In 2001 (i.e. ~20 years later) they find a use for them. Is that thinking ahead or what! Good thing some bits were reserved back in the early ’80s.
To enable the TCP receiver to determine when to stop setting the ECN-Echo flag, ‘they’ introduced a second new flag in the TCP header, the CWR flag.  The CWR flag is assigned to Bit 8 in the Reserved field of the TCP header.

        0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
      |               |                       | U | A | P | R | S | F |
      | Header Length |        Reserved       | R | C | S | S | Y | I |
      |               |                       | G | K | H | T | N | N |

Above is the old definition of bytes (not bits) 13 and 14 of the TCP header defined in RFC 793.

        0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
      |               |               | C | E | U | A | P | R | S | F |
      | Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
      |               |               | R | E | G | K | H | T | N | N |

Above: The new definition of bytes 13 and 14 of the TCP Header defined in RFC 3168.

This stuff gets pretty crazy and RFC 4774 in 2006 attempts to improve on ECN but, I just need a break from this series.

Before I finish, look below at how Scrutinizer v7’s NetFlow reporting displays the ECN bits.  Coooool or what?


I wonder if we could use these ECN bits in NetFlow to represent congestion on the network…… Thanks for reading.

Mike Patterson author pic


Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.


Leave a Reply