From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x242.google.com (mail-la0-x242.google.com [IPv6:2a00:1450:4010:c03::242]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C713A21F09E; Mon, 18 May 2015 10:17:35 -0700 (PDT) Received: by labgd6 with SMTP id gd6so894198lab.3; Mon, 18 May 2015 10:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N495Yyx7JhdNmS3BI5fJDxy4/HdnIklocoO2U7/WPVM=; b=Rm9iLZ48po3qosHS6dd1ANXzSEsV0iXk3hf9vIwjcKQGASSVQ8vfykdbgE5y8z1pXe bJQN0GyRsTtyEnVsWnvk/B2g1uRS6Nz/wICIMDLokatY3MOvaVjBw1n2LlkoCGUFukvj Y/v42i6fdOB4BYcFPCHCTY2GPfOMkXg7ZzFyZ7KlRDJuHN3CGgpeFtl488gup9JfzwRK E8mIw/ZQt2Fk/CUIrBntVmmLVL6oLmiabQy9dRT5+Nv33UquN+/lQEN++45Ln54pt+Ht LmIf5g+WoQXannTDmCylaQuv2QhUKuNyx77XlwKzvWwGazcaqQR37W7NN7UTem2tsOdm bjOw== X-Received: by 10.112.138.195 with SMTP id qs3mr17502682lbb.47.1431969445503; Mon, 18 May 2015 10:17:25 -0700 (PDT) Received: from bass.home.chromatix.fi (37-136-63-124.rev.dnainternet.fi. [37.136.63.124]) by mx.google.com with ESMTPSA id lf12sm2845926lac.38.2015.05.18.10.17.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 10:17:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: <8E2F7EDC-3356-451A-8EFA-023A1EED4F0F@gmx.de> Date: Mon, 18 May 2015 20:17:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <25D8D287-B5E9-49A9-B47E-4C7122884E1C@gmail.com> 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> To: Sebastian Moeller X-Mailer: Apple Mail (2.2098) Cc: "Klatsky, Carl" , Simon Barber , cake@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, 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 17:18:25 -0000 X-List-Received-Date: Mon, 18 May 2015 17:18:25 -0000 X-List-Received-Date: Mon, 18 May 2015 17:18:25 -0000 X-List-Received-Date: Mon, 18 May 2015 17:18:25 -0000 X-List-Received-Date: Mon, 18 May 2015 17:18:25 -0000 > On 18 May, 2015, at 20:03, Sebastian Moeller wrote: >=20 >> Adding Diffserv and recommending that LEDBAT applications use the >> =E2=80=9Cbackground=E2=80=9D 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? I don=E2=80=99t 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=E2=80=99s slightly less = serious if general best-effort traffic gets CS1 markings. 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. 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. I=E2=80=99m not sure whether it=E2=80=99s 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. - Jonathan Morton