[Bloat] configuration on an OpenVPN server

[Bloat] configuration on an OpenVPN server

[Matt Taggart]

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 don't have much control of the VPN client hosts, but I could recommend 
openvpn settings if there is anything that would help (can you turn on 
ecn there, etc?)

Thanks,

-- 
Matt Taggart
matt@lackof.org

Re: [Bloat] configuration on an OpenVPN server

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]


Matt Taggart <matt@lackof.org> wrote:
    > 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, on the clients it would be nice to autoconfigure what their slice of
this is!  To do this nicely, really, one needs some bandwidth estimators that
can be placed on the outside of the encrypted packets.

    > I don't have much control of the VPN client hosts, but I could recommend
    > openvpn settings if there is anything that would help (can you turn on ecn
    > there, etc?)

Communicating the estimates should ideally be part of the OpenVPN protocol.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Bloat] configuration on an OpenVPN server

[Toke Høiland-Jørgensen]

Matt Taggart <matt@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