From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 F0DB921F205; Mon, 18 May 2015 11:37:15 -0700 (PDT) Received: by obcus9 with SMTP id us9so136446993obc.2; Mon, 18 May 2015 11:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VOgpMv6egJ/MGoAZOtj1985iPzAjZKkrEVu1RPK21jg=; b=AkM+7rNDgk9UswLNh4ApuD1F6nBQzxY8kqmpjbhQMqYtzimybq2uLQUaXpvVdlg/Of niirD31MQ/t1RSON6XexL2baXaRy5eqvbaA97lBLOZQUZyvfpZwP0Q8HL5as1rtCj2eU j5FVGh7X+2PjcWnJA/uf8Yv0EP+m2af3/DPwIOmDC+S2gnOKKWB0hLkjvT7kcUwb5PjS 98DTTDHUAQQQqvivoyKmzP9EZi81ztlPj7UcaGgS0Sp8Leo3egZGylH8vJJLi+HI7Ej5 ly9P6FP3+ZzPfkyn+DdkwC7RWJ+2a3M36sWI8m7SljQZGUUHXJI2cWmFfNoSsvTVRxGf YvUQ== MIME-Version: 1.0 X-Received: by 10.60.103.36 with SMTP id ft4mr14087769oeb.39.1431974227385; Mon, 18 May 2015 11:37:07 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Mon, 18 May 2015 11:37:07 -0700 (PDT) In-Reply-To: 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> Date: Mon, 18 May 2015 11:37:07 -0700 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Klatsky, Carl" , cake@lists.bufferbloat.net, "David P. Reed" , cerowrt-devel , bloat , Jonathan Morton Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 X-List-Received-Date: Mon, 18 May 2015 18:38:14 -0000 On Mon, May 18, 2015 at 11:14 AM, Sebastian Moeller wrote= : > HI Jonathan, > > On May 18, 2015, at 19:17 , Jonathan Morton wrote= : > >> >>> On 18 May, 2015, at 20:03, Sebastian Moeller wrote: >>> >>>> Adding Diffserv and recommending that LEDBAT applications use the >>>> =E2=80=9Cbackground=E2=80=9D traffic class (CS1 DSCP) solves this prob= lem 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. >>> >>> I wonder, for this to work well wouldn't we need to allow/honor at leas= t CS1 marks on ingress? I remember there was some discussion about mislabel= ed traffic on ingress (Comcast I believe), do you see an easy way around th= at 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 mana= ge internal congestion. If latency-sensitive and/or inelastic traffic is g= etting marked CS1, that would be a real problem, and Comcast would need lea= ning on to fix it. It=E2=80=99s slightly less serious if general best-effo= rt traffic gets CS1 markings. > > I do not know any further details, but I think Dave noted that or= iginally, maybe he knows what was mislabeled. all bits except the CS1 bit are masked out on comcast, it seems. qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 1500 target 5.0ms interval 100.0ms ecn Sent 1177316772 bytes 16370274 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 2626475 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 130: parent 1:13 limit 1001p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn Sent 234497554050 bytes 187934189 pkt (dropped 3368, overlimits 0 requeues= 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 32445438 ecn_mark 77 new_flows_len 1 old_flows_len 2 >> >> One solution would be to re-mark the traffic at the CPE on ingress, usin= g local knowledge of what traffic is important and which ports are associat= ed with BitTorrent. > > In theory that sounds sweet, in practice this is hard I believe, = as there is not simple =E2=80=9Cmark=E2=80=9D of bitttotrrent traffic, the = TOS bits might be the best we have (if bittorrent would actually mark itsel= f 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 ingres= s action before passing it to the qdisc. Either that, or a pseudo-qdisc wh= ich 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 modu= le would also need to incorporate act_mirred functionality, or a minimal su= bset thereof. > > For this to be of practical issue we first need to solve the ques= tion how to detect incoming bit torrent packets, so we have a need for rema= rking facilities ;) > If I recall correctly the nf_tables developers are working hard ATM to ge= t 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=3D2 about n= f_tables on ingress. (I noticed in that discussion that our need to use tra= ffic-shapers (instead of policers) on the ingress does seem to be on the de= velopers radar, but I could be wrong ) At the moment based on the brutal after effects of watching the dslreports "fiber" test I am leaning towards something more policer-like on inbound so long as dumber rate shapers exist at the isp. > Best Regards > Sebastian > >> >> - Jonathan Morton >> > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67