Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simple-tc reduces bandwidth far below given limit #1447

Closed
RalfJung opened this issue Jun 26, 2018 · 5 comments
Closed

simple-tc reduces bandwidth far below given limit #1447

RalfJung opened this issue Jun 26, 2018 · 5 comments
Labels
0. type: bug This is a bug

Comments

@RalfJung
Copy link
Contributor

I have set

uci set simple-tc.mesh_vpn.limit_ingress=10000
uci set simple-tc.mesh_vpn.limit_egress=1000
uci commit simple-tc && /etc/init.d/tunneldigger restart

With these settings, when I do a speedtest, I get <3 MBit/s download speed (and ~1 MBit/s upload as expected).

With an ingress limit of 30000, download speed increases to ~5 MBit/s.

When I turn off simple-tc, I get 25 MBit/s for downloads (my DSL line has 30 MBit/s so that's as expected).

Seems like simple-tc reduces the download speed much further than it should? I had a look at the device load during these tests, but there was always >50% idle.

This is with a WR841N/ND v10 and a firmware based on Gluon v2018.1.8, in a tunneldigger/l2tp-based network.

@neocturne
Copy link
Member

TL;DR: ingress filters are bad, the behaviour is known.

We don't have any way to control how fast a VPN peer sends traffic; such a feature would need to be implemented in the VPN software, or possibly a layer on top of the VPN that transmits the limit and installs an egress filter on the other side.

The only thing our ingress filter does is to drop packets when we are over the limit, and hope that TCP connections behave sanely and reduce throughput. For non-TCP protocols, the situation is even worse, as they often do not have any kind of control (so they will simply experience packet loss when the ingress filter kicks in). And even for TCP, behaviour in the presence of packet loss can be very bad with some TCP implementations, especially when there are multiple parallel TCP streams.

@RalfJung
Copy link
Contributor Author

I see. So what one would want is for tunneldigger to tell the broker on the gateway side to please do egress filtering. I can see how that makes more sense. :)
I think I even saw TODOs for that somewhere in the tunneldigger sources or so.

I can look into adding support for that in tunneldigger. Does simple-tc have support for cooperating with the VPN client in that regard?

@kaechele
Copy link
Contributor

Tunneldigger already has that support (-L flag on the client makes the server set the requested downstream bandwidth limit). It's just that the support on the Gluon side is missing to actually pass that flag to tunneldigger when

  1. a limit is set in config mode and
  2. tunneldigger is the method used for VPN.

@rotanid
Copy link
Member

rotanid commented Jul 25, 2018

fixed by d87c4b5

@rotanid rotanid closed this as completed Jul 25, 2018
@RalfJung
Copy link
Contributor Author

Awesome, thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. type: bug This is a bug
Projects
None yet
Development

No branches or pull requests

4 participants