[Bloat] configuration on an OpenVPN server

[Toke Høiland-Jørgensen]

Matt Taggart <matt at lackof.org> writes:

> Hi,
>
> I would like to configure SQM on an OpenVPN server and I am thinking 
> about how to do this. I have already setup piece_of_cake on the upstream 
> connection(in this case 900Mbit down/250Mbit up). I think that by itself 
> should do a decent job of keeping things fair between all the VPN 
> clients: they are assigned private IPs and triple-isolate should do the 
> right thing.
>
> But OpenVPN creates a tun device for that traffic and I could 
> potentially do more to manage the VPN traffic separately from the server 
> host traffic. One thing that occurred to me is that due to asymmetric 
> upload/download the host has, and the fact that the VPN traffic has to 
> go to/from the client, maybe the download rate of the tun device will 
> never exceed the upload rate of the host (since we need to retransmit 
> that data to the clients) and vice versa for the upload? So to force 
> myself to be a bottleneck should I have qdiscs on the tun device 
> limiting to ~240Mbit in each direction?
>
> Hopefully that is clear. Let me know if it's not. Also anything else I 
> should consider in this situation?

I think what you're saying is that all the VPN traffic goes back out the
same link, right? I.e., there are no other links on that server (to a
LAN or something) that the traffic can go out?

In that case, yeah, the ingress traffic should mostly be limited by the
egress since it all needs to be forwarded anyway (assuming the clients
are not accessing any services on the host itself either). I run a
similar setup for a tor bridge, and I just have this on the egress:

qdisc cake 8006: dev eth0 root refcnt 2 bandwidth 100Mbit besteffort flows nonat nowash no-ack-filter no-split-gso rtt 100.0ms raw overhead 0 

This keeps both ingress and egress traffic pretty much exactly at a
steady 100 Mbps (which means it eats up about 1 terabyte of data a day
:)).

One additional wrinkle you may get with OpenVPN is that the VPN driver
itself can suffer from bufferbloat. So when you shape the underlying
link, packets will queue in the tun device first, adding delay. You
could maybe fix this by shaping the tun device as well, but it's not
obvious what bandwidth to shape at, since that will depend on the
ingress/egress distribution of your clients. And I'm no even sure
traffic going from one VPN client to another will pass through the tun
device...

-Toke