Windows 10, Outbound TCP always on ECN (Explicit Congestion Notification) CE(Congestion experienced) codepoints

tcpwindows

I've found something interesting recently while doing some random packet captures. I enabled my Windows's ECN capability years ago while it was on windows 8 that time. I had it updated when windows 10 was available so I am not sure whether it is enabled by default or what.

Anyway I am all for ECN, it's a nice feature to have but I observed something strange in my wireshark: almost all the outbound TCP SYN is marked with CE(0x03):
Windows screenshot

same computer in linux with ECN enabled, which shows normal behaviour(0x01 or 0x02):
linux screenshot

is it a bug or feature that they just wanted to be nice to everyone so they marked it with an extra-slow start tcp? I'm sure that my computer is not congested…

EDIT: some wording

Best Answer

That's not a bug, that's how ECN works between TCP endpoints.

Host A sends a SYN with ECN and CWR flags set to let host B know that it wants to use ECN. If Host B supports ECN, it should SYN-ACK with the ECN bit set.

Once ECN has been negotiated, the ECT information can be set in the IP header which is what you are seeing when looking at the (non-SYN) capture on your Linux host.

From RFC3168:

Before a TCP connection can use ECN, Host A sends an ECN-setup SYN packet, and Host B sends an ECN-setup SYN-ACK packet. For a SYN packet, the setting of both ECE and CWR in the ECN-setup SYN packet is defined as an indication that the sending TCP is ECN-Capable, rather than as an indication of congestion or of response to congestion.

Related Topic