From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 B31023B2A3 for ; Sat, 22 Apr 2017 18:35:19 -0400 (EDT) Received: by mail-wr0-x235.google.com with SMTP id z109so72065033wrb.1 for ; Sat, 22 Apr 2017 15:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tK9BDTcYVOchpLi3xy2ZhXJXAd2exAVY4UBZgyWMQUc=; b=CHombxH2gDlAodeCdT+JCk4qBqhMKGCWaUoGpWznlUDG9zIJ5eoDF/sjyhK2oUMwU5 Im12jrXJA05EciQmypOIF4mRUSbdmvxZIAlGMnWsOdChGZAMhQg7PwjeOrtjjJ+3hswd PRIhfAGzGTXqy3S+PtF3MqdKf8HhYRwIIxToYWA8My5lvQZ297lx1CXC7a3hGOs9EJNj Gw4b4UYWzwfm3Cw9A3n0FeWsWP6vZl4MIL0wzryvcARDgAfQdKbUeD15CZ3mQQRe3AS4 KlkRtnzPfKE36R+UTFJXFe1gjki6yq9fviZgn72NKT85psi6oVVChTCz60hPDji+/JTx AP+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tK9BDTcYVOchpLi3xy2ZhXJXAd2exAVY4UBZgyWMQUc=; b=Lf6v7nDuEuyC+LooV6fUcBhAtIMz8yuyeuC+Mg2dZ08GRFyiW+FJRORfAkW09v24dK 4CQYY2n0bVoOS1oZctGTOPnUTXpmGs+lLPzbAcRNyE1njJ9xPI0j7c9XxYNAll4R2/p7 A1hQcf+/8mfR1NVR+EMbaSWgCS+YHp6ZPsFBK4FcKC8fcwFssRM+hVC0jUh/2o/gKW2R 1/LgOMt/rG94TBPjV/m4pRxsRnxW7g2uAAAE7e0N+DcS0fmaGvfEDxJHwSNBJ7BVIAwS /BdnCH16I6CQ6cAl4/kUOgSAaoez/0Cq/pwIZvxsWqF2lZko92PSCmz4iWKKpToZyCbY q9Cg== X-Gm-Message-State: AN3rC/4+Ck0bLcKUTBJBSlzTjuORJ3n+YLzLb37d/GNCe0Al+SyQ3cit G5B4bg0ge2OJ4g== X-Received: by 10.223.133.133 with SMTP id 5mr2733271wrt.83.1492900518752; Sat, 22 Apr 2017 15:35:18 -0700 (PDT) Received: from [192.168.0.3] (185.182.7.51.dyn.plus.net. [51.7.182.185]) by smtp.gmail.com with ESMTPSA id v52sm12257555wrc.53.2017.04.22.15.35.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Apr 2017 15:35:17 -0700 (PDT) To: Dendari Marini , Sebastian Moeller Cc: cake@lists.bufferbloat.net References: <05C0B0C7-4337-4115-AC6B-DA81392FCB34@gmail.com> <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <0BA3EE91-C5BC-4155-9D5D-D15D34490A1A@gmx.de> From: Andy Furniss Message-ID: Date: Sat, 22 Apr 2017 23:35:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 22 Apr 2017 22:35:19 -0000 Dendari Marini wrote: > Hello, thank you all for your replies! > > For the overhead I'm gonna use "pppoe-llcsnap" (or "overhead 40 atm), > as I believe it's the one which should work best for my connection. I seem to have confused my self as to whether you are using raw or not. If you are not then I think that shaping on pppoe just overhead 40 atm will be 22 bytes too little .... Maybe what version of tc and or cake matters here, I don't know. Maybe others could comment on that. One simple test is set your up bandwidth just a little below your syn rate and upload while pinging somewhere - if you are over then the pings will rise. In theory you should be able to run up almost at line rate - back off a tiny bit to allow for LCP. As you have a highly asymmetric connection you don't really want to sacrifice more upload than is needed. A lot of your up bandwidth will be needed just for acks. > About the per-host fairness download issue: while it's kinda resolved > I still feel like it's mainly related to Steam, as normally > downloading files from PC1 and PC2 halved the speed as expected even > at full bandwidth (so no overhead, no -15%). Shaping too close to the real bandwidth is somewhat exposed more when there are many connections involved. > Anyway back to Steam: assuming the IP addresses aren't a big issue, > what steps should I follow to start filtering its traffic so it's > considered background? Would the DPI from the ER-X be any helpful? It's a shame steam doesn't allow you to tell it to set tos/dscp like some torrent clients do. You could then use connmark to classify the incoming. Whatever method you find to identify steam downloads it may be a bit hit and miss with the dscp marking as on ingress you need to get tc to call iptables, which seems to need a bit of luck with versions matching up properly. Maybe on a pure router (ie. no significant traffic from wan to router) you could consider shaping inbound traffic on the lan side. 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. tc qdisc add dev ppp0 ingress tc filter add dev ppp0 parent ffff: prio 1 protocol ip u32 match u32 0 0 action connmark continue tc filter add dev ppp0 parent ffff: prio 2 protocol ip handle 1 fw action xt -j DSCP --set-dscp-class cs1 action mirred egress redirect dev ifb0 tc filter add dev ppp0 parent ffff: prio 3 protocol ip handle 2 fw action xt -j DSCP --set-dscp-class cs4 action mirred egress redirect dev ifb0 tc filter add dev ppp0 parent ffff: prio 4 protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 If you use ipv6 you would need to handle that as this is ipv4 only.