From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E27C43B25D for ; Sun, 1 May 2016 10:47:23 -0400 (EDT) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A45153801B2; Sun, 1 May 2016 10:47:23 -0400 (EDT) Received: from app51.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 930B438015E; Sun, 1 May 2016 10:47:23 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app51.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Sun, 01 May 2016 10:47:23 -0400 Received: from reed.com (localhost [127.0.0.1]) by app51.wa-webapps.iad3a (Postfix) with ESMTP id 80CF16121C; Sun, 1 May 2016 10:47:23 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 1 May 2016 10:47:23 -0400 (EDT) Date: Sun, 1 May 2016 10:47:23 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" Cc: "Ben Greear" , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , "ath10k" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <57258F41.8040600@candelatech.com> X-Auth-ID: dpreed@reed.com Message-ID: <1462114043.512818296@apps.rackspace.com> X-Mailer: webmail/12.4.1-RC Subject: Re: [Make-wifi-fast] =?utf-8?q?fq=5Fcodel=5Fdrop_vs_a_udp_flood?= X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 14:47:23 -0000 Maybe I missed something, but why is it important to optimize for a UDP flo= od?=0A=0AA general observation of control theory is that there is almost al= ways an adversarial strategy that will destroy any control regime. Sometime= s one has to invoke an "oracle" that knows the state of the control system = at all times to get there.=0A=0ASo a handwave is that *there is always a DD= oS that will work* no matter how clever you are.=0A=0AAnd the corollary is = illustrated by the TSA. If you can't anticipate all possible attacks, it is= not clearly better to just congest the whole system at all times with cont= rols that can't possibly solve all possible attacks - i.e. Security Theater= . We don't want "anti-DDoS theater" I don't think.=0A=0AThere is an alterna= tive mechanism that has been effective at dealing with DDoS in general - tr= ack the disruption back to the source and kill it. (this is what the end-t= o-end argument would be: don't try to solve a fundamentally end-to-end prob= lem, DDoS, solely in the network [switches], since you have to solve it at = the edges anyway. Just include in the network things that will help you sol= ve it at the edges - traceback tools that work fast and targeted shutdown o= f sources).=0A=0AI don't happen to know of a "normal" application that bene= fits from UDP flooding - not even "gossip protocols" do that!=0A=0AIn conte= xt, then, let's not focus on UDP flood performance (or any other "extreme c= ase" that just seems fun to work on in a research paper because it is easy = to state compared to the real world) too much.=0A=0AI know that the reactio= n to this post will be to read it and pretty much go on as usual focusing o= n UDP floods. But I have to try. There are so many more important issues (l= ike understanding how to use congestion signalling in gossip protocols, gam= ing, or live AV conferencing better, as some related examples, which are en= d-to-end problems for which queue management and congestion signalling are = truly crucial).=0A=0A=0A=0AOn Sunday, May 1, 2016 1:23am, "Dave Taht" said:=0A=0A> On Sat, Apr 30, 2016 at 10:08 PM, Ben Greear = wrote:=0A>>=0A>>=0A>> On 04/30/2016 08:41 PM, Dav= e Taht wrote:=0A>>>=0A>>> There were a few things on this thread that went = by, and I wasn't on=0A>>> the ath10k list=0A>>>=0A>>> (https://www.mail-arc= hive.com/ath10k@lists.infradead.org/msg04461.html)=0A>>>=0A>>> first up, ud= p flood...=0A>>>=0A>>>>>> From: ath10k = on behalf of Roman=0A>>>>>> Yeryomin =0A>>>>>> Sent= : Friday, April 8, 2016 8:14 PM=0A>>>>>> To: ath10k@lists.infradead.org=0A>= >>>>> Subject: ath10k performance, master branch from 20160407=0A>>>>>>=0A>= >>>>> Hello!=0A>>>>>>=0A>>>>>> I've seen performance patches were commited = so I've decided to give it=0A>>>>>> a try (using 4.1 kernel and backports).= =0A>>>>>> The results are quite disappointing: TCP download (client pov) dr= opped=0A>>>>>> from 750Mbps to ~550 and UDP shows completely weird behavour= - if=0A>>>>>> generating 900Mbps it gives 30Mbps max, if generating 300Mbp= s it gives=0A>>>>>> 250Mbps, before (latest official backports release from= January) I was=0A>>>>>> able to get 900Mbps.=0A>>>>>> Hardware is basicall= y ap152 + qca988x 3x3.=0A>>>>>> When running perf top I see that fq_codel_d= rop eats a lot of cpu.=0A>>>>>> Here is the output when running iperf3 UDP = test:=0A>>>>>>=0A>>>>>> 45.78% [kernel] [k] fq_codel_drop=0A>>>= >>> 3.05% [kernel] [k] ag71xx_poll=0A>>>>>> 2.18% [kern= el] [k] skb_release_data=0A>>>>>> 2.01% [kernel] [k] r4k= _dma_cache_inv=0A>>>=0A>>>=0A>>> The udp flood behavior is not "weird". Th= e test is wrong. It is so=0A>>> filling=0A>>> the local queue as to dramati= cally exceed the bandwidth on the link.=0A>>=0A>>=0A>> It would be nice if = you could provide backpressure so that you could=0A>> simply select on the = udp socket and use that to know when you can send=0A>> more frames??=0A> = =0A> The qdisc version returns NET_XMIT_CN to the upper layers of the=0A> = stack in the case=0A> where the dropped packet's flow =3D the ingress packe= t's flow, but that=0A> is after the=0A> exhaustive search...=0A> =0A> I don= 't know what effect (if any) that had on udp sockets. Hmm... will=0A> look.= Eric would "just know".=0A> =0A> That might provide more backpressure in t= he local scenario. SO_SND_BUF=0A> should interact with this stuff in some s= ane way...=0A> =0A> ... but over the wire from a test driver box elsewhere,= tho, aside=0A> from ethernet flow control itself, where enabled, no.=0A> = =0A> ... but in that case you have a much lower inbound/outbound=0A> perfor= mance disparity in the general case to start with... which can=0A> still be= quite high...=0A> =0A>>=0A>> Any idea how that works with codel?=0A> =0A> = Beautifully.=0A> =0A> For responsive TCP flows. It immediately reduces the = window without a RTT.=0A> =0A>> Thanks,=0A>> Ben=0A>>=0A>> --=0A>> Ben Gree= ar =0A>> Candela Technologies Inc http://www.cand= elatech.com=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4ht=0A> Let's go make home= routers and wifi faster! With better software!=0A> http://blog.cerowrt.org= =0A> _______________________________________________=0A> Make-wifi-fast mai= ling list=0A> Make-wifi-fast@lists.bufferbloat.net=0A> https://lists.buffer= bloat.net/listinfo/make-wifi-fast=0A> =0A