UDP Packet drop

[CptCAveMan]

I originally used EE Broadband but needed a fixed IP, so I switched to BT. Unfortunately, I was mis-sold by BT, so I moved back to EE. Since then, I’ve noticed problems when streaming video from my home to another location.

After investigating, I discovered that the EE network is dropping UDP packets.

I’ve spoken with EE support over the phone, but their tests only check TCP traffic (speed, jitter, and packet loss), so everything appears normal on their end. It didn’t help that the engineer I spoke with didn’t know the difference between TCP and UDP. After a lot of back and forth, I was told there was no issue—though I could book an engineer visit. However, the engineer’s tests would also be TCP-based, so they wouldn’t reveal the problem.

I know the issue isn’t with my local setup. I’ve tested with both the EE router and my own, swapped cables for known working ones, and even tried a modem dongle—where the problem disappears completely.

Finally, with the help of a friend, I captured Wireshark data showing that UDP packets are indeed being lost.

My question is: how should I proceed from here?

[Christopher_G]

Hi @CptCAveMan 

Welcome to the community.

I'm presuming that the support team asked you to restart your router, and other basic broadband troubleshooting.

Since you have those test results through Wireshark, it's definitely worth contacting our Technical Support team, to show them that information. Hopefully, they can help raise a ticket against your account for investigation.

Keep us posted on what happens please.

Chris

[bobstothard]

I'm getting the exact same issue however the UDP traffic is my work VPN

Summary:
I am experiencing persistent packet loss when using UDP-based connections on my EE broadband line. This affects services that rely on UDP traffic such as Cloudflare Warp and VPN connections using the UDP protocol. TCP-based connections work normally with no loss or instability.

Technical Details:

• I use my own router (Ubiquiti EdgeRouter X) connected via PPPoE to EE broadband.

• To rule out my hardware, I tested using the EE-supplied router and observed the same issue — UDP traffic experiences packet loss, while TCP traffic remains stable.

• When I route all traffic through a NordVPN TCP tunnel, the packet loss disappears entirely.

• When using a NordVPN UDP tunnel, the problem reappears inside that VPN session.

• This behaviour indicates that UDP packets are being lost or mishandled somewhere on EE’s network path before they reach the destination.

Impact:

• Cloudflare Warp cannot maintain a stable connection.

• UDP‑based VPNs drop packets and perform poorly.

• Only by “hiding” UDP traffic inside a TCP VPN tunnel does connectivity remain reliable.

I feel that calling support is just going to be a waste of time, and will be fobbed off just as you were, very frustrating!!!!

[Lesley_W]

Hi @bobstothard 

Welcome to our community.

I'm sorry to see you are having this trouble and feel like you aren't getting the help you need from the support team. At any time when you are speaking to a guide, if you don't feel happy with a resolution or that they aren't addressing your concerns, you can ask to make a complaint and escalate it if needed. 

You can also make a complaint a number of ways that you can see here Make a Complaint.

Hope this helps.

Lesley

[bobstothard]

Hi Lesley,

I logged a ticket with support yesterday and was told that they were
creating some kind of 'escalated ticket' 12/11. Still not had any contact
from anyone as yet.

[Lesley_W]

I'm pleased the team have been able to open a ticket for you @bobstothard 

The team will be looking into it and will provide an update as soon as they are able to. 

Lesley

[HomeNetworkGuy]

It seems EE has a wider problem with high priority DSCP marked UDP: https://community.ee.co.uk/t5/Broadband-Landline/Microsoft-Teams-Quality-Issue/td-p/1527842/page/12

BT Home Hub 2 has been recommended by users to workaround this, it probably remarks the DSCP to 0 (thus avoiding the high DSCP marked problem).

[marc5000]

The issue is clear:

• UDP traffic marked as DSCP 0 (best effort); goes through fine. No limits.
• UDP traffic marked as DSCP 46 (EF - ie. high priority); is throttled to a few hundred kb, then packets start dropping.

BT/EE claim there is no QoS or queues; but I don't believe this. There must be a QoS manager on these newer Smart Hubs, or this issue can't be manifesting.

We've been working with a customer who has a Smart Hub 6, and this is a real concern...

So where is the issue manifesting; on some hidden QoS manager on the new Smart Hub 6, or at the network level? 

@Lesley_W @Christopher_G  -- can this issue be escalated to a higher level, please? This is a cause for concern, EF marked UDP data should follow the correct RFC, which is 30% of bandwidth. So someone with a 100Mbps upload trunk should only start seeing EF packets capped at 30Mbps, not 200-500Kbps.

Many thanks

[bobpullen]

---

@marc5000 wrote:

BT/EE claim there is no QoS or queues; but I don't believe this. There must be a QoS manager on these newer Smart Hubs, or this issue can't be manifesting.

---

I think you may be looking at it the wrong way round, @HomeNetworkGuy is likely onto something with their earlier post.

Both the Smart Hub and the broadband network will have the ability to manage/prioritise traffic. For the latter, have a read of the BT SIN document here that I've just uncovered from a quick Google search. From page 21: -

"Real Time QoS is supported on all WBC end user access variants. There are two elements to this
service:

i) Each EP is configured so that up to 5% of capacity can be sent as Real Time bandwidth
(i.e. IP packets marked DSCP EF). 
ii) The CP must order an amount of Real Time bandwidth for each End User line that
requires the service. The RTQoS end user allocations are symmetrical and apply in both
upstream and downstream directions

Real Time QoS End User Access bandwidth allocations are symmetrical and allowable rates are
350kbit/s, 1000kbit/s, 1900kbit/s, 2800kbit/s and 4900kbit/s"

Now that document might not be current, but I doubt it's that far off the mark. Read: there's not a huge amount of EF bandwidth to play with (and I imagine EE would want control of what it should/shouldn't be made up of).

This is a cause for concern, EF marked UDP data should follow the correct RFC, which is 30% of bandwidth. So someone with a 100Mbps upload trunk should only start seeing EF packets capped at 30Mbps, not 200-500Kbps.

---

If you consider the doc referenced above, I reckon this is a tad presumptuous for a residential broadband service; we're likely talking much lower levels of bandwidth - and it's probably optimistic to assume that a residential broadband network is going to honour traffic weightings that are applied by (non-EE) software/hardware residing on somebody's local network.

---

@HomeNetworkGuy wrote:

BT Home Hub 2 has been recommended by users to workaround this, it probably remarks the DSCP to 0 (thus avoiding the high DSCP marked problem).

---

This from an earlier post ^

Worth considering that the crux of the issue might be certain hubs not undoing/ignoring the locally-applied prioritisation? Would seem a little silly to honour it when there's potentially so little high priority bandwidth to play around with out on the network 🤔