TCP CWR Flag and ECN PCAP Analysis: Diagnose CE, ECE, and Congestion Without Packet Loss

Throughput can fall even when a TCP trace contains few retransmissions because ECN-capable routers may mark congestion instead of dropping packets. Start at the SYN exchange to confirm ECN negotiation, then correlate IP CE marks with TCP ECE and CWR flags and the sender's rate response. The PCAP can establish congestion signaling visible at the capture point; it cannot reveal every queue that applied a CE mark or prove a middlebox blocks ECN without comparison traffic.

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.

Prove the ECN sequence across IP and TCP before judging performance

ECN analysis can go wrong when an engineer searches only for the CWR flag, sees only the IP header, or starts the PCAP after the handshake. The useful narrative has a sequence: endpoints negotiate ECN capability, an ECT-capable packet is marked CE somewhere on the path, the receiver reflects congestion with ECE, and the sender acknowledges a congestion response with CWR. Some implementations and paths vary, so the trace should support the exact sequence observed rather than force every packet into a textbook pattern.

| Evidence item | Where to inspect it | What it supports | What it does not prove alone | |---|---|---| | ECN-capable SYN/SYN-ACK | TCP flags during handshake | The endpoints attempted/accepted a relevant ECN mode. | That every middlebox preserves markings later. | | ECT codepoint | IP ECN bits on data packets | Data packets are eligible to carry ECN congestion signaling. | That a router actually marked congestion. | | CE codepoint | IP ECN bits on received packets | A packet arrived at the capture point marked Congestion Experienced. | Which exact queue/device made the mark. | | ECE flag | TCP receiver feedback | The receiver is reporting congestion to the sender. | That throughput drop is caused only by ECN. | | CWR flag | TCP sender response | The sender signals a congestion-window response. | The size, duration, or effectiveness of that response without rate evidence. | | Timing/rate window | Payload sequence, ACKs, RTT, and throughput over time | Whether behavior changes around the marking event. | Application intent or every bottleneck on the path. |

Keep packet direction explicit. A CE mark may be observed on a packet traveling to the receiver; the receiver's ECE feedback travels back toward the sender; the sender's CWR travels forward again. Mixing directions is a common reason an otherwise correct trace becomes an incorrect incident summary.

A practical ECN PCAP workflow

1. Retain the three-way handshake. Verify what the endpoints attempted before interpreting later ECE/CWR flags. A midstream capture can still show useful congestion evidence, but it cannot fully establish negotiation.
2. Create a bounded analysis window. Include a stable baseline, the first CE/ECE event, the sender response, and enough later traffic to compare rate, ACK cadence, RTT, and retransmissions. Do not isolate a single marked packet without context.
3. Inspect IP ECN and TCP flags together. A display filter or summary should preserve codepoints and flags rather than stripping packet headers during export. Note capture offload considerations and use a capture point appropriate to the question.
4. Separate congestion from loss. Count retransmissions, duplicate acknowledgments, SACK evidence, and timeouts independently. ECN can accompany loss, but a CE mark is not a dropped packet. The TCP SACK and DSACK analysis guide helps keep loss and reordering evidence distinct.
5. Compare a controlled path change. When possible, compare ECN enabled/disabled, direct/VPN, alternate load balancer, or a known-good path while holding application workload and capture placement as constant as possible. A before/after capture is stronger than a claim based on one slow trace.
6. State the observed boundary. For example: “ECN negotiation is visible; CE-marked packets reach the receiver; ECE/CWR follow; throughput falls without a matching retransmission burst.” That is a useful conclusion without claiming which router queue was full.

PCAP Surgery is designed for retaining this evidence chain in a case rather than exporting a tiny snippet that omits the handshake or the post-marking response. The capture scope help covers a defensible packet window, and the slow HTTP request guide shows how transport signals should be separated from application wait time.

Distinguish ECN from similar slow-throughput patterns

Pattern	What a trace may show	Why it is not automatically ECN	Next comparison
Packet loss	Retransmissions, duplicate ACKs, SACK recovery, or timeout	Loss can reduce rate without CE/ECE/CWR.	Analyze recovery and loss location separately.
Receiver window pressure	Small or zero advertised receive window	The receiver may be the limiting side even on a clean path.	Compare receive-window evolution and application reads.
Application delay	Long gaps before request/response bytes	The network can be healthy while the server waits.	Correlate packet timing with application logs if available.
Queue delay	Rising RTT/ACK spacing with or without marks	Delay alone does not prove ECN marking.	Look for ECN bits and consistent directionality.
Capture artifact/offload	Odd checksums, segmentation patterns, or missing visibility	Local capture behavior can mislead packet interpretation.	Capture at a second point or account for offload.

Can a firewall or middlebox break ECN?

It can interfere by dropping or rewriting ECN-capable traffic, clearing bits, or behaving differently on a specific path. A single PCAP may reveal a compatibility symptom, but it rarely proves the responsible device. Capture a controlled comparison on the relevant path and preserve the SYN exchange, later IP ECN bits, TCP flags, and endpoint behavior.

Does no retransmission mean the network is healthy?

No. A connection can suffer queue delay, ECN signaling, receiver-window limitation, application stalls, shaping, or a path issue that does not create visible retransmissions in the captured interval. ECN is important precisely because it can signal congestion before packet loss becomes the dominant clue.

Should we disable ECN to fix a production incident?

Treat that as a controlled compatibility test, not a universal cure. If disabling ECN changes the symptom, retain both before/after traces and investigate the path or endpoint behavior. Changing a network-wide setting without evidence can remove useful congestion feedback while masking the actual incompatibility.

What should a PCAP report say about CE marks?

Say where the marked packet was observed, its direction and timing, whether ECN negotiation is visible, whether ECE/CWR feedback follows, and how throughput/RTT/retransmissions behave around the event. Do not name an exact router or queue unless a capture or telemetry source at that boundary supports it.

The useful ECN conclusion is evidence-led: congestion signaling is visible, its transport response can be measured, and competing explanations have been checked. That makes a “slow but no loss” incident reviewable by network, transport, and application teams without turning a few header bits into a speculative root cause.

How do you validate an ECN finding in a bounded packet window?

Select a window that begins before the first relevant CE-marked packet and continues through the receiver’s ECE feedback, sender’s CWR response, and enough later traffic to observe recovery or continued pressure. Record capture point, flow tuple, direction, TCP option negotiation, sequence range, IP ECN bits, TCP flags, RTT/ACK spacing, retransmissions, receive window, and throughput behavior. A screenshot of one marked packet is not an ECN analysis.

Evidence step	What it can establish	What it cannot establish alone
ECT in SYN/handshake and data	Endpoint/path attempted ECN-capable transport	Every middlebox preserved it
CE on an IP packet	Congestion was marked before this observation point	Exact queue or device responsible
ECE from receiver	Receiver echoed observed congestion	Sender reduced its sending behavior
CWR from sender	Sender acknowledged congestion feedback	Performance recovered for the application
Post-event flight	Transport timing/loss response	Root cause outside the captured boundary

Compare a similar unmarked interval on the same path and, if possible, a second capture point. If disabling ECN is used as a compatibility experiment, change only that variable and retain both traces; do not present it as the permanent remedy until the responsible path behavior is known. Check receiver-window limits, application gaps, shaping, offload, and capture loss before attributing all slow throughput to CE marks.

The final report should state observed signaling, transport response, performance correlation, and the remaining unobserved boundary. Preserve the reduced evidence using the PCAP Surgery capture scope guide and use timestamp rewrite evidence when cross-sensor clock alignment affects the conclusion.

Include the packet numbers or stable flow-relative references used for each claim, so another analyst can reopen the evidence window and independently reproduce the ECN sequence without searching the entire capture.

<!-- multilingual-related-reading:start -->

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:

• TCP CLOSEWAIT and FINWAIT PCAP Analysis: Finding Connection Leaks, Half-Closes, and Shutdown Bugs
• TCP MSS Clamping and VPN PCAP Analysis: Finding Oversized Segments, MTU Mismatch, and Slow Tunnels
• TCP RST and Connection Reset PCAP Analysis: Who Closed the Connection and Why

<!-- multilingual-related-reading:end -->