TCP ECN PCAP Analysis: CE Marks, ECE, CWR, Congestion Without Loss, and Middlebox Compatibility

Explicit Congestion Notification lets a network signal congestion without dropping packets. Users search for "TCP ECN pcap", "CE mark Wireshark", "ECE CWR flags", "congestion without packet loss", "ECN negotiation failed", and "middlebox blocks ECN" when throughput changes but retransmissions do not explain the behavior.

PCAP Surgery is useful because ECN evidence is split across IP header bits, TCP handshake negotiation, TCP flags, and later congestion response. If the capture is trimmed incorrectly, the important handshake and marked packets may disappear.

What ECN shows

ECN can show congestion before packet loss. Routers can mark packets with Congestion Experienced instead of dropping them. The receiver reports this to the sender with ECE, and the sender acknowledges response with CWR.

Useful evidence:

• ECN capability in SYN/SYN-ACK.
• ECT bits in IP headers.
• CE-marked packets.
• ECE flag from receiver.
• CWR flag from sender.
• Throughput change after congestion notification.

This gives a different diagnosis from loss-driven retransmission analysis.

ECN negotiation

ECN must be negotiated during connection setup. A trace that starts after the handshake may not show whether ECN was enabled.

Preserve:

• SYN.
• SYN-ACK.
• ACK completing handshake.
• TCP flags.
• IP ECN field.
• Any middlebox rewriting.

Without the handshake, ECN interpretation is incomplete.

CE marks

CE marks indicate congestion experienced on the path. They do not mean the packet was lost. The packet arrived, but with a congestion signal.

This matters for support cases where graphs show:

• No retransmissions.
• No obvious loss.
• Reduced throughput.
• Increased latency.
• Queue management behavior.
• Congestion control response.

The pcap can prove whether the network signaled congestion without dropping data.

ECE and CWR flags

ECE and CWR appear in TCP flags.

Diagnostic questions:

• Does the receiver echo congestion with ECE?
• Does the sender respond with CWR?
• Are ECE flags repeated?
• Does throughput reduce after marks?
• Does a firewall strip ECN bits?
• Does the path bleach ECN markings?

These details help distinguish actual congestion signaling from capture artifacts.

Middlebox compatibility

Some middleboxes mishandle ECN. Problems include:

• Clearing ECN bits.
• Dropping ECN-capable SYN packets.
• Passing SYN but clearing later marks.
• Misreporting flags after NAT.
• VPN encapsulation losing ECN state.
• Load balancer behavior differs per path.

If a connection works with ECN disabled but fails with ECN enabled, preserve before/after pcaps.

False loss diagnosis

ECN can reduce sending rate without retransmissions. If an engineer expects congestion to mean packet loss, they may miss CE/ECE/CWR evidence.

Good analysis separates:

• Packet loss.
• Queue delay.
• ECN marking.
• Receiver window pressure.
• Application slowness.
• Capture offload artifacts.

Debug checklist

Use this workflow:

1. Keep the TCP handshake.
2. Confirm ECN negotiation.
3. Inspect IP ECN field.
4. Find CE-marked packets.
5. Find ECE responses.
6. Find CWR sender response.
7. Compare throughput before and after marks.
8. Check retransmissions separately.
9. Compare paths through VPN or load balancer.
10. Preserve before/after ECN enabled captures.

Final diagnosis

TCP ECN analysis explains congestion without packet loss. The evidence is in ECN negotiation, CE marks, ECE flags, CWR flags, and sender response.

PCAP Surgery helps keep the handshake, marked packets, and response window together so ECN behavior is not mistaken for random slow throughput.