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?

[marc5000]

Hi @chafos,

You raise a fair point about the workaround, and yes, remarking traffic to DSCP 0 would likely bypass the EF throttling issue (we know it does). However, I think this misses the bigger picture of what we're asking for here...

The issue isn't that we can't work around it — it's that we shouldn't have to. DSCP EF exists for a reason: real-time applications like VoIP, video conferencing, and VPNs mark their traffic this way because they genuinely need low-latency, low-jitter handling. The applications themselves are setting these markings — Zoom, Teams, Cloudflare Warp, WireGuard — not power users tweaking QoS settings for fun.

As for your suggestion to "unmark the UDP traffic": in many cases, this isn't straightforward. For enterprise VPN clients or managed applications, end users often don't have control over how traffic is marked. And even where it's technically possible (e.g., using iptables to mangle DSCP on egress), asking residential customers to implement firewall rules to work around their ISP's network configuration is a pretty poor customer experience.

The core problem remains: the current EF limit of ~350kbps is far too restrictive for modern usage patterns. As @bobpullen pointed out, the BT SIN document suggests up to 5% of capacity for Real Time bandwidth, with allocations up to 4900kbps available. Even if residential lines get the lower end of that, we're still talking about significantly more than what's currently being enforced.

What we're asking is for EE to either increase the EF allocation to something reasonable (a percentage-based approach would make sense), or clearly document this limitation so customers can make informed decisions. Right now, it's an undocumented gotcha that breaks legitimate applications. 

The other option is to adapt the firmware of BT/EE routers to scrub EF tagged packets and just treat all network traffic as DSCP 0; this ensuring bandwidth for when it matters. 

The amount of BT/EE customers we've heard from recently (for our own software) is quite astounding; they just want to work without these limitations -- and reasonably so; they think they have enough upload bandwidth!

[CptCAveMan]

Sorry for the delay in responding on this issue — I have been out of the country for a period of time.

Firstly, thank you to everyone for the work and effort that has gone into investigating this so far. It’s appreciated.

I agree that EE do need to take action to resolve this issue. In its current state, the problem is preventing me from using my software as intended, which is not a sustainable position.

I do have concerns regarding the proposed solution of using BT/EE routers to scrub tagged packets. While this may address the immediate symptom, it effectively forces us into a dependency on specific hardware, which is not an acceptable long-term solution and limits flexibility unnecessarily.

In my view, the appropriate resolution needs to be implemented within EE’s core network itself, so that the issue is addressed holistically rather than mitigated at the edge. A network-wide fix would avoid hardware lock-in and provide a more robust and scalable outcome for all parties involved.

I’m keen to work collaboratively toward a solution that resolves the root cause and ensures compatibility without imposing restrictive infrastructure requirements.

[HomeNetworkGuy]

EE needs to want to fix it, but they don't. 

I escalated through the retention team, spoke to the complaints dept, got released from my contract and moved to Vodafone Broadband, problem solved.

[marc5000]

@HomeNetworkGuy - Yep, and that's because Vodafone just treat EF traffic (scrub it) as best effort. The reality is that EF through the core will be costly, so I'm guessing EE have it because they think it might be beneficial to their VoIP home phone service, or something?

---

I escalated through the retention team, spoke to the complaints dept, got released from my contract and moved to Vodafone Broadband, problem solved.

---

You've missed the most important bit. This wasn't disclosed to you, neither in your contract nor the EE network traffic policy; which actually states there are no limitations or prioritisations...

Why didn't you contact Ofcom?

[HomeNetworkGuy]

Because I didn't want to spend any more time trying to fix EE's problem. 

[bobpullen]

---

@HomeNetworkGuy wrote:

EE needs to want to fix it, but they don't. 

---

I suspect they do. It would make no sense not to, given the implications on widely used applications like Teams/Zoom etc. There's acknowledgement on that linked thread that the right people are aware of the issue.

---

@marc5000 wrote:

The other option is to adapt the firmware of BT/EE routers to scrub EF tagged packets and just treat all network traffic as DSCP 0; this ensuring bandwidth for when it matters. 

---

Seems the logical/cost-efficient thing to do.

@CptCAveMan - what application are you using to stream and does it have some sort of prioritisation feature that's within your control? In your Wireshark captures, does the differentiated services value show that your streaming traffic is EF tagged?

[CptCAveMan]

@HomeNetworkGuy So I have issues with Teams, however the application i am using is called Vemotion is low latency video streaming software.

Speaking with one of the Devs he has put in a DSCP Marking setting so it can be changed to 0 and now that works. I am of course happy that it is now usable however not happy about what they are doing and now telling people.

It's as bad as O2 blocking port 8000 on cellular but activly denying it when you call them.

[bobstothard]

For anyone else who comes across this post, This is how I fixed it for
myself. This isn't with a BT or EE router though, i use an EdgeRouter X

set firewall modify SOURCE_ROUTE rule 5 description "Scrub DSCP EF(46) on
UDP to DSCP 0"
set firewall modify SOURCE_ROUTE rule 5 action modify
set firewall modify SOURCE_ROUTE rule 5 protocol udp
set firewall modify SOURCE_ROUTE rule 5 dscp 46
set firewall modify SOURCE_ROUTE rule 5 modify dscp 0

No packet loss when using Cloudflare WARP anymore

[HomeNetworkGuy]

Yeah it annoyed the hell out of me.  I solved the issue myself by moving to Vodafone, saved on the cost of my broadband and resolved the problem. Whether the Vodafone home router is resetting the DSCP to 0 or there's a different path with Vodafone that doesn't over police the higher DSCP values is a question, either way, it's not my problem anymore. 🙂

[Wavemachine]

I have just had my laptop upgraded at work, new laptop with Teams app everything seemed fine however colleagues reported my audio breaking up, no video or very poor quality jerky video, screen sharing working baddly. Works fine on office Wifi just home EE, hardwired or Wifi.

Old Dell laptop works fine.

Swapped to a new TP Link router, has not fixed or improved the issue. We saw a lot of packet loss reported in teams call quality as well as low bit rate.

Did some tests today by recording teams test call abd could see what my colleagues were seeing. New laptop has Intel Connectivity Performance Suite, disabled Advanced Settings Prioritisation and it seems to have resolved the issue.

I will log it with EE as saying Video calling is not something consumers should be doing is wrong, a lot of home working, talking to friends/family, online therapy sessions, the list goes on.