Re: [Bloat] configuration on an OpenVPN server
Matt Taggart 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. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] BBR implementations, knobs to turn?
Hi Erick, one question about the PGW: is it a policer or a shaper that you have installed? Also, have you tried to run a ping session before and in parallel to the curl sessions? Luca On Thu, Nov 19, 2020 at 2:15 PM wrote: > Update: > The 5G router was connected to a new base station. Now the limiting > factor of throughput is the policer on the PGW in mobile core, not the > radio link itself. The SIM card used is limited to 30Mbit/s. This > scenario favours the new server. I have attached graphs comparing radio > link limited vs PGW policer results, and a zoomed in graph of the policer > > > We have Huawei RAN and Ericsson RAN, rate limited and not rate limited > subscriptions, 4G and 5G access, and we are migrating to a new core with > new PGW (policer). Starting to be a bit of a matrix to set up tests for. > > > -Erik > > > > Fra: Jesper Dangaard Brouer > Sendt: 17. november 2020 16:07 > Til: Taraldsen Erik; Priyaranjan Jha > Kopi: bro...@redhat.com; ncardw...@google.com; bloat@lists.bufferbloat.net > Emne: Re: [Bloat] BBR implementations, knobs to turn? > > On Tue, 17 Nov 2020 10:05:24 + wrote: > > > Thank you for the response Neal > > Yes. And it is impressive how many highly qualified people are on the > bufferbloat list. > > > old_hw # uname -r > > 5.3.0-64-generic > > (Ubuntu 19.10 on xenon workstation, integrated network card, 1Gbit > > GPON access. Used as proof of concept from the lab at work) > > > > > > new_hw # uname -r > > 4.18.0-193.19.1.el8_2.x86_64 > > (Centos 8.2 on xenon rack server, discrete 10Gbit network card, > > 40Gbit server farm link (low utilization on link), intended as fully > > supported and run service. Not possible to have newer kernel and > > still get service agreement in my organization) > > Let me help out here. The CentOS/RHEL8 kernels have a huge amount of > backports. I've attached a patch/diff of net/ipv4/tcp_bbr.c changes > missing in RHEL8. > > It looks like these patches are missing in CentOS/RHEL8: > [1] https://git.kernel.org/torvalds/c/78dc70ebaa38aa3 > [2] https://git.kernel.org/torvalds/c/a87c83d5ee25cf7 > > Could missing patch [1] result in the issue Erik is seeing? > (It explicitly mentions improvements for WiFi...) > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] configuration on an OpenVPN server
Matt Taggart 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 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
