From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3207C21F210; Mon, 18 May 2015 11:15:45 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.68.160]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lp3sy-1ZQSbH1zm8-00esDp; Mon, 18 May 2015 20:14:59 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <25D8D287-B5E9-49A9-B47E-4C7122884E1C@gmail.com> Date: Mon, 18 May 2015 20:14:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1431919815.385726792@apps.rackspace.com> <55597353.2010408@superduper.net> <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1431961775.459218261@apps.rackspace.com> <8E2F7EDC-3356-451A-8EFA-023A1EED4F0F@gmx.de> <25D8D287-B5E9-49A9-B47E-4C7122884E1C@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:ESGFFIyvGNDOIS1+VfoyEpnnKkz+/PTU5sMqkukPvnWSA7c3y74 DU9EGH+zEmFV5467rvwnX8SRl8Y/ntNErKM3fwTTsacCN217v1DAb97Ip2lRyXSgZxZui3G jPqJaQMVd59akMa8mFst2gBUd86AR/go0jOgNWVOCQf5zAMpWV9qmI7DyH7650dbux/IvIf TcwCsVKb6RR3mOLL9vIVQ== X-UI-Out-Filterresults: notjunk:1; Cc: "Klatsky, Carl" , Simon Barber , cake@lists.bufferbloat.net, cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 18:16:44 -0000 X-List-Received-Date: Mon, 18 May 2015 18:16:44 -0000 X-List-Received-Date: Mon, 18 May 2015 18:16:44 -0000 X-List-Received-Date: Mon, 18 May 2015 18:16:44 -0000 X-List-Received-Date: Mon, 18 May 2015 18:16:44 -0000 HI Jonathan, On May 18, 2015, at 19:17 , Jonathan Morton = wrote: >=20 >> On 18 May, 2015, at 20:03, Sebastian Moeller wrote: >>=20 >>> Adding Diffserv and recommending that LEDBAT applications use the >>> =93background=94 traffic class (CS1 DSCP) solves this problem more >>> elegantly. The share of bandwidth used by BitTorrent (say) is then >>> independent of the number of flows it uses, and it also makes sense = to >>> configure FQ for ideal flow isolation rather than for mitigation. >>=20 >> I wonder, for this to work well wouldn't we need to allow/honor at = least CS1 marks on ingress? I remember there was some discussion about = mislabeled traffic on ingress (Comcast I believe), do you see an easy = way around that issue? >=20 > I don=92t know much about the characteristics of this mislabelling. = Presumably though, Comcast is using DSCP remarking in an attempt to = manage internal congestion. If latency-sensitive and/or inelastic = traffic is getting marked CS1, that would be a real problem, and Comcast = would need leaning on to fix it. It=92s slightly less serious if = general best-effort traffic gets CS1 markings. I do not know any further details, but I think Dave noted that = originally, maybe he knows what was mislabeled. >=20 > One solution would be to re-mark the traffic at the CPE on ingress, = using local knowledge of what traffic is important and which ports are = associated with BitTorrent. In theory that sounds sweet, in practice this is hard I believe, = as there is not simple =93mark=94 of bitttotrrent traffic, the TOS bits = might be the best we have (if bittorrent would actually mark itself CS1) = and we already discussed how unsatisfactory this solution is. > Unfortunately, the ingress qdisc runs before iptables, making that = more difficult. I think it would be necessary to do re-marking using an = ingress action before passing it to the qdisc. Either that, or a = pseudo-qdisc which just does the re-marking before handing the packet up = the stack. >=20 > I=92m not sure whether it=92s possible to attach two ingress actions = to the same interface, though. If not, the re-marking action module = would also need to incorporate act_mirred functionality, or a minimal = subset thereof. For this to be of practical issue we first need to solve the = question how to detect incoming bit torrent packets, so we have a need = for remarking facilities ;) If I recall correctly the nf_tables developers are working hard ATM to = get nf_tables working on ingress as well. There are a few threads on = netdev e.g. http://marc.info/?l=3Dnetfilter-devel&m=3D143153372615155&w=3D= 2 about nf_tables on ingress. (I noticed in that discussion that our = need to use traffic-shapers (instead of policers) on the ingress does = seem to be on the developers radar, but I could be wrong ) Best Regards Sebastian >=20 > - Jonathan Morton >=20