Net neutrality is typically framed as a policy debate (see my background Net Neutrality post here), but its real implications are observable in packet-level behavior. For network engineers and broadband technicians, the question is not abstract: can you see evidence of blocking, throttling, or prioritization in a packet capture?
Using Wireshark, it is possible to translate regulatory policy and principles into measurable network characteristics. However, doing so requires discipline, controlled testing, and a clear understanding of normal (nominal) versus abnormal behavior. At the packet level, net neutrality is not a single observable event. It is a pattern recognition exercise across flows, time, and protocols. Blocking, throttling, and prioritization each leave distinct fingerprints, but none can be confirmed in isolation. The network technician/engineer’s role is to combine packet evidence with controlled testing and network context to determine whether observed behavior is:
- Normal/Nominal network operation
- Or indicative of traffic discrimination
This is where Wireshark moves from being a packet viewer to a forensic instrument for Internet behavior analysis. Let’s do some definitions and explanations followed by a lab exercise using a synthetic set of captures to observe these possible packet-level behaviors.
Blocking: Failure at Connection Establishment
At the packet level, blocking is the easiest neutrality violation to detect. It manifests as failure to establish a connection. For example, in a normal TCP flow, you expect to see the three-way handshake (3WHS):
- SYN – connection request by the receiver
- SYN-ACK – connection accepted by the sender
- ACK – agreement/confirmation by the receiver
When blocking occurs, this process breaks down. In Wireshark, this may appear as repeated SYN packets with no response, indicating that the destination is not reachable or is intentionally filtered or blocked. Alternatively, you may see immediate TCP reset (RST) packets or ICMP “administratively prohibited” messages.
The challenge is attribution. A failed handshake does not automatically imply ISP-level blocking. The failure could originate from the server, an intermediate firewall, or a routing issue. Therefore, validation requires comparing multiple destinations and testing across different paths or networks.
Throttling: Throughput and Flow Degradation Trends
Throttling is more subtle. It does not prevent communication; instead, it artificially constrains performance.
In packet captures, throttling appears as:
- Consistently low throughput despite available bandwidth
- Reduced TCP window sizes
- Frequent zero-window conditions
- Elevated retransmission rates under otherwise stable conditions
Wireshark’s TCP analysis tools are critical here. Time-sequence graphs and throughput visualizations can reveal patterns such as a connection that ramps up and then plateaus at an artificial ceiling. However, engineers must distinguish between:
- Legitimate congestion control
- Wi-Fi or RF issues
- Server-side limitations
- True policy-driven throttling
The defining characteristic of throttling is repeatability tied to application type, not random degradation.
Paid Prioritization: Unequal Treatment of Traffic
Paid prioritization, often described as “fast lanes,” is reflected in how different traffic flows are treated relative to each other.
At the packet level, this can be observed through:
- DSCP (Differentiated Services Code Point) markings in the IP header
- Differences in latency, jitter, and packet loss between flows
- Queueing behavior under load
For example, a VoIP stream may exhibit low latency and minimal jitter, while a bulk file transfer experiences delay and retransmissions. This alone is not a violation—QoS is a legitimate engineering practice.
The critical distinction is whether prioritization is based on technical requirements (e.g., real-time traffic) or tied to economic arrangements or specific applications. Packet captures can show the existence of prioritization, but determining intent requires correlation with policy and service agreements.
Transparency: Detecting the Undisclosed
Transparency violations are the hardest to detect because they involve undisclosed behavior rather than explicit blocking or throttling.
Engineers can identify anomalies by comparing things like:
- The same content over different protocols (TCP vs QUIC)
- The same destination with and without a VPN
- Performance across different times of day
If one class of traffic consistently performs differently without a clear technical reason, it may indicate undisclosed traffic management practices. This type of analysis requires controlled experiments and careful statistical comparison, not just a single packet capture.
A Synthetic Hands-On Lab: Detecting Net Neutrality Behaviors in PCAPs
This lab is designed for broadband technicians and network engineers to observe both normal and suspicious behaviors using Wireshark. To get ready for this exercise, you will need Wireshark installed, my suggested NetNeutrality profile installed (you can download that here), and the following ZIP file, unzipped with five .pcapng files:
You will analyze five PCAP scenarios. Keep in mind these are synthetic examples of individual events so you can see how to identify the violations using the profile provided. In the wild, you will be looking for these as repeated behaviors across multiple flows, and even then it may be difficult to prove conclusively that certain policies are in place on a given network. Also, I do not address the exact location of the policy enforcement. That is an entire separate subject.
PCAP 01: standard https download – think of this as a Baseline Traffic
Normal TCP/TLS-like session with healthy handshake, request, segmented response, cumulative ACKs, and graceful close.
PCAP 02: example violation using blocking – SYN drop
Client repeatedly transmits SYN packets to the target with exponential-style retry spacing and receives no SYN-ACK.
PCAP 03: example violation using blocking – TCP RST
Connection attempt is immediately terminated with a TCP RST+ACK, representing an administrative block or active interference.
PCAP 04: example violation – throttled download
Same general transaction pattern as the baseline file, but the response is artificially rate-limited:
- many small 536-byte segments
- long inter-packet gaps
- much longer completion time
PCAP 05: example QoS markings high vs best effort priority at L3
Reference file showing DSCP EF-marked RTP-like traffic alongside best-effort bulk UDP. This is included to understand that QoS marking itself is not automatically a neutrality violation.
OK – with everything in place, let’s begin.
Step 1
Open 01 and 04 side by side or on two screens so you can compare them – both with the NetNeutrality profile:
Be sure to watch title bars on windows and pop up windows to make sure you are looking at the right things.
A quick overview of both captures, you should note that both have good TCP connections, both transferred data and ended correctly. However you should note a couple of differences.
Step 2
Note the overall time it takes to transfer the 01 conversation: last packet (Frame 27) occurs at 0.192199 seconds – that is 192 milliseconds. Compared with the 04 capture, the last packet is frame 64, at it occurred at 5.481005 seconds.
Further if we look at the SEQ # of TCP in both of those last frames we see 01 file is 15214, and the 04 file it is 14584. These represent the number of bytes transferred – very similar yet even being slightly larger, the 01 file transferred in milliseconds.
Step 3
Open Statistics> Conversations from both capture file so you can compare them:
Clearly the 04 file is being constrained which accounts for the longer time it took to transfer a similar sized conversation.
Step 4
Close those conversation windows. Now select Statistics>TCP stream graph> Graphs on both:
We clearly see the timeline ranges being different, buy we also note the difference in the number of round trip times (each stair step is a RTT) and in the case of the 04 transfer this not only adds time, but also adds network overhead.
Step 5
Within those two graph windows, there is an option/drop down on the lower left for the Type of graph. Change both to Throughput:
Here you can plainly see that the 01 transfer was allowed to accelerate without any visible limitation, while the 04 transfer hit some limit and then was forced to stay at that limit, again causing delay in completion.
You can close both pop-up windows and both Wireshark instances.
Step 6
Now open the 02 and the 03 capture files in two separate Wireshark instances for comparison, again using the NetNeutrality profile.
These look substantially different.
Looking at the 02 capture first, we see a SYN request, and then 3 retries only. There is no completed TCP session. This is an example of a classic “nothing comes back” pattern. This is a blocking by dropping behavior example.
Now, looking at the 03 capture, we observe and immediate TCP reset after SYN. The TCP connection is prevented very early and this stopped any retransmissions. This indicates an active blocking action instead of passive silence as we saw in the 02 capture.
In the profile, if you select the TCP dropdown of the display filter button, you will see some important filters associated with Net Neutrality research:
- The SYN’s + SYN ACK’s – this would be normal – we would look for pairs. Any non-paired SYN’s may be the silent block. You could also try this filter “tcp.flags.syn == 1 && tcp.flags.ack == 0”
- Retransmissions: does exactly that, shows all TCP retransmissions
- Zero Windows – this is when TCP says stop transmitting – always interesting to try and figure out why
- Resets – quickly display all the resets so you can zoom in on them.
Step 7
You can close all Wireshark windows.
Now open the 05 file in Wireshark:
This capture has different L3 QoS markings. The high priority frames are shown in yellow with a red lettering color rule in the profile so they stand out.
Put the following filters into the Display Filter, and observe the difference:
- udp.port == 40002
- udp.port == 53001
You should have observed that EF (DSCP 46) marks are on an RTP-like flow. RTP is usually associated with Voice or Video traffic. You also should have observed best-effort marks on the bulk flow. Just because the packets have different QoS marking does not mean anything by itself. This could be deliberate engineering QoS, whereas policy discrimination is something different. Policy discrimination is going to be applied to all traffic type to or from a specific destination most likely. The challenge then is to differentiate between “prioritization exists” vs “paid prioritization violation” instances. Not so simple.
I hope you found the content and the lab exercise useful.
Comments are welcomed below from registered users. You can also leave comments at our Discord server.
If you would like to see more content and articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!