From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E2E5E3B2A3 for ; Tue, 25 Apr 2017 07:24:21 -0400 (EDT) Received: by mail-wm0-x22f.google.com with SMTP id w64so19886141wma.0 for ; Tue, 25 Apr 2017 04:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5iybaufw9KdKaBPRUkWfc5pBowjCbT8KwqrjTo3baFQ=; b=O2JDP2ZMLhHWERgszN2whzGj+bOuLKS1teWbIe9p8bKEDuaBxop20MlLG7+TgdPuy2 y+HQu9jzpNdYnhJvfH8Y3KMKoTarZ065VG3In8yG73vrrjwfAhNl43zP0WCNDF2+oOoZ PHm401JEUvEi/0iTGxcUMRk9AYnBQB9Br7wtdfeWJGeA6Fnqhaml/15XIFq1iQg0s8eL rJZhXf6eZOTroF7SnXKQgo5jXGgrb0qzwQif8ivJuGH+70hYEtTU3szr7TTC73hW0Gtn B7+I6bGbMQvNvhx48aI7RCv7nhqu0c07w6jpi9armrHcoQxat8NnktITlYd33DXD/NVq uU2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5iybaufw9KdKaBPRUkWfc5pBowjCbT8KwqrjTo3baFQ=; b=soeUcgVCbuKSlVD1oma1jnVB5AmUTlCx5BeggbZrfYX0aXaWAh8rT7u5Ux3YEPsX56 b33kCnE/yUbJhkghu08tvkfY4vGz8Ckp/cB6+uYgyy+4Peudk7i6KAgJaOcUUTRunv7k pegRp1fSF4mYVE3f3C43Bh4xNouX+AvCM+wNZo7XLOVZs9Hx1143TJ1R0NiQ4yCDVmCU BlBwy2FkD1c6PD9EphvERYqy/wMjOHsRAl99qSYvmd8sCdmdIDtwG30rHPvKlOloUBEB MLOW+i8vPJnsOfGHhSH4Zf6DWeLulz9d0ae9Pll2SWzfAh5T50o962kd+PJi/A4DaCBA nhjQ== X-Gm-Message-State: AN3rC/4Wz4ofI+Tu4M+KLELbKs5CMEJ+GeM3PfGMhDiwFNXeZIFGv6s4 FSKw6VIvbf+Pbcm4XB2GAHf3wG7buQ== X-Received: by 10.80.174.188 with SMTP id e57mr4642639edd.166.1493119460806; Tue, 25 Apr 2017 04:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.169.59 with HTTP; Tue, 25 Apr 2017 04:24:20 -0700 (PDT) In-Reply-To: References: <05C0B0C7-4337-4115-AC6B-DA81392FCB34@gmail.com> <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <0BA3EE91-C5BC-4155-9D5D-D15D34490A1A@gmx.de> <00DDAA0B-7D99-489B-BA2D-1F20289409B3@gmx.de> <2FFBF256-2932-4FC7-AD1F-0D7CEE111809@gmx.de> From: Dendari Marini Date: Tue, 25 Apr 2017 13:24:20 +0200 Message-ID: To: Andy Furniss Cc: Sebastian Moeller , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=f403045c4578119438054dfbf73a Subject: Re: [Cake] Getting Cake to work better with Steam and similar applications X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:24:22 -0000 --f403045c4578119438054dfbf73a Content-Type: text/plain; charset=UTF-8 Hello, I think the easiest and most robust way to shape ingress traffic for you > would be to do it on the LAN side. > If you have multiple interfaces facing LAN then use ifb. > I've never used it myself, but to mark multiple address ranges the > easiest way would be to use iptables with ipset - there will be many > examples to be found on the internet. > Even if you do mark (well set dscp cs1) for steam servers you will still > need to be backed off from your ingress rate enough or it still won't > work as the queue will build up too much on the ISP side of the > bottleneck. Shaping ingress is quite different to doing egress as you > are at the wrong end of the bottleneck. In my case switch0 should work for the LAN, just wondering if setting cake on both pppoe0 (for outbound traffic) and switch0 (fro inbound traffic) at the same time should work without issues? Hmm, probably gonna try it and see if it does. I'm gonna look up iptables and ipset and see what I can find, thanks for the help. Also I have done some more testing, I was able to limit Steam connections just to one thanks to some console commands ("@cMaxContentServersToRequest" and "@cCSClientMaxNumSocketsPerHost") and while the situation improved (no more packet loss, latency variation within 10ms, but still seeing ping spikes of ~50ms) it's still not what I'd consider ideal, which would be like with any other download. So my guess is there's something else going on other than just the multiple connections, which are definitely big part of the problem but not the only thing. Anyway these are my current settings for Cake and I've been using them for the last four days without issues: *qdisc cake 8005: root refcnt 2 bandwidth 950Kbit diffserv3 triple-isolate nat wash rtt 100.0ms atm overhead 40 via-ethernet* *qdisc cake 8006: root refcnt 2 bandwidth 17500Kbit diffserv3 triple-isolate nat wash ingress rtt 100.0ms atm overhead 40 via-ethernet* I will try Andy's suggestions and see what I can do. @Sebastian No problem, I tested your updated script and it is indeed reporting overhead 40. On 25 April 2017 at 12:26, Andy Furniss wrote: > Dendari Marini wrote: > > FWIW here's a quick example on ingress ppp that I tested using >>> connmark the connmarks (1 or 2 or unmarked) being set by iptables >>> rules on outbound connections/traffic classes. >>> >> >> >> Unfortunately I'm really not sure how to apply those settings to my >> case, it's something I've never done so some hand-holding is probably >> needed, sorry. At the moment I've limited the Steam bandwidth using >> the built-in Basic Queue and DPI features from the ER-X. They're easy >> to set up but aren't really ideal, would rather prefer Cake would >> take care about it more dynamically. >> >> Anyway about the Steam IP addresses I've noticed, in the almost three >> weeks of testing, they're almost always the same IP blocks (most of >> which can be found on the Steam Support website, >> https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711). >> I believe it would be a good starting point for limiting Steam, what >> do you think? >> > > I think the easiest and most robust way to shape ingress traffic for you > would be to do it on the LAN side. > If you have multiple interfaces facing LAN then use ifb. > I've never used it myself, but to mark multiple address ranges the > easiest way would be to use iptables with ipset - there will be many > examples to be found on the internet. > Even if you do mark (well set dscp cs1) for steam servers you will still > need to be backed off from your ingress rate enough or it still won't > work as the queue will build up too much on the ISP side of the > bottleneck. Shaping ingress is quite different to doing egress as you > are at the wrong end of the bottleneck. > --f403045c4578119438054dfbf73a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I think the easiest and most = robust way to shape ingress traffic for you
would be to do it on the LAN side.
If you have multiple interfaces facing LAN then use ifb.
= I've never used it myself, but = to mark multiple address ranges the
easiest way would be to use iptables with ipset - there will be manyexamples to be found on the intern= et.
Even if you do mark (well se= t dscp cs1) for steam servers you will still
need to be backed off from your ingress rate enough or it stil= l won't
work as the queue wi= ll build up too much on the ISP side of the
bottleneck. Shaping ingress is quite different to doing egress = as you
are at the wrong end of t= he bottleneck.

In my case switch0 sh= ould work for the LAN, just wondering if setting cake on both pppoe0 (for o= utbound traffic) and switch0 (fro inbound traffic) at the same time should = work without issues? Hmm, probably gonna try it and see if it does. I'm= gonna look up iptables and ipset and see what I can find, thanks for the h= elp.

Also I have done some more testing, I was abl= e to limit Steam connections just to one thanks to some console commands (&= quot;@cMaxContentServersToRequest" and "@cCSClientMaxNumSocketsPe= rHost") and while the situation improved (no more packet loss, latency= variation within 10ms, but still seeing ping spikes of ~50ms) it's sti= ll not what I'd consider ideal, which would be like with any other down= load. So my guess is there's something else going on other than just th= e multiple connections, which are definitely big part of the problem but no= t the only thing.

Anyway these are my current sett= ings for Cake and I've been using them for the last four days without i= ssues:

qdisc cake 8005: root refcnt 2 bandwidth= 950Kbit diffserv3 triple-isolate nat wash rtt 100.0ms atm overhead 40 via-= ethernet
qdisc cake 8006: root refcnt 2 bandwidth 1750= 0Kbit diffserv3 triple-isolate nat wash ingress rtt 100.0ms atm overhead 40= via-ethernet

I will try Andy's sugges= tions and see what I can do.

@Sebastian No problem= , I tested your updated script and it is indeed reporting overhead 40.=C2= =A0

On= 25 April 2017 at 12:26, Andy Furniss <adf.lists@gmail.com> wrote:
Dendari Marini = wrote:

FWIW here's a quick example on ingress ppp that I tested using
connmark the connmarks (1 or 2 or unmarked) being set by iptables
rules on outbound connections/traffic classes.


Unfortunately I'm really not sure how to apply those settings to my
case, it's something I've never done so some hand-holding is probab= ly
needed, sorry. At the moment I've limited the Steam bandwidth using
the built-in Basic Queue and DPI features from the ER-X. They're easy to set up but aren't really ideal, would rather prefer Cake would
take care about it more dynamically.

Anyway about the Steam IP addresses I've noticed, in the almost three weeks of testing, they're almost always the same IP blocks (most of
which can be found on the Steam Support website, https://support.steampowered.com/kb_article.php?ref= =3D8571-GLVN-8711).
I believe it would be a good starting point for limiting Steam, what
do you think?

 I think the easiest and most robust way to shape ingress traffic for you would be to do it on the LAN side.
If you have multiple interfaces facing LAN then use ifb.
I've never used it myself, but to mark multiple address ranges the
easiest way would be to use iptables with ipset - there will be many
examples to be found on the internet.
Even if you do mark (well set dscp cs1) for steam servers you will still need to be backed off from your ingress rate enough or it still won't work as the queue will build up too much on the ISP side of the
bottleneck. Shaping ingress is quite different to doing egress as you
are at the wrong end of the bottleneck.

--f403045c4578119438054dfbf73a--