From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 808AC3B260; Mon, 2 May 2016 10:03:49 -0400 (EDT) Received: by mail-oi0-x22a.google.com with SMTP id v145so157041048oie.0; Mon, 02 May 2016 07:03:49 -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-transfer-encoding; bh=/VRyWdqc8APgNvSdxBed9FPnPIlbe+l97PGikB0MLpY=; b=bVmCvqejRpgmgYqy8TaUFimX44niL6d22R2mHBvPv+F5OGwAD7kLoUWO3HcFntnEHs B8DtNQgNTIhmfaPiJwtTDuBoY6gL9v+dK58Q2/Dg45r4loZkxt3fIGLY5bOIsYSGLV0w UwpvIB7CsYFPiwWYRSbkdGIes7d2IscFIfBMvDC2uVKhi8OpGlORUP1POm6Uq2Ic9332 AXQ649PFSnJb/NCnAjW88ggKNHmbH64lQ25NKsMcKiWDjz2GWNH+Zwb6nX/6TtoiEZtn FKVC/fTqHUGEaUrtdygphYw4Ii/fKrhey7hedp9dPdugTEYbvlAv1gHsRU0J80FfCgov HhwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=/VRyWdqc8APgNvSdxBed9FPnPIlbe+l97PGikB0MLpY=; b=eVcRd05oipTqtnHQFIsSWS3Eclh1GTr9EK5CncRa63sD/44v4laedq0AKXmTl561Up TXjhy+Xsf8+3uYZ3Dmc6srvD3O2t6XC7XrNPfItKR4QHZq+hZ7bYIrY8TW8M0CUfjnDf JKdboyyjBb1/w39CjquKM42Pe6C9uiOq2Tr63s+JMseF139T4RcLtQvuv85FnyVRND8i 6oUJ03WOn9b/K8nP+zQhB4QPgViByuU2QWegHF71C/qhRNhUJGS+N7WrqLE6jernHN7S azbRepgjp39Bl7vz60ItUtzL3C7e18MF5d9JoNYcsUduTmmegn0DRWj8AGFELgfl81sA 1gkw== X-Gm-Message-State: AOPr4FXCW8Ox1ffYSrxyptNyUqGYagmXAMCU8x1D82itHycNzGWyXnO/0ggT45fklroYyn6Yso+xLuYK7OEW+g== MIME-Version: 1.0 X-Received: by 10.157.57.138 with SMTP id y10mr15186675otb.64.1462197828736; Mon, 02 May 2016 07:03:48 -0700 (PDT) Received: by 10.202.79.195 with HTTP; Mon, 2 May 2016 07:03:48 -0700 (PDT) In-Reply-To: <1462114043.512818296@apps.rackspace.com> References: <57258F41.8040600@candelatech.com> <1462114043.512818296@apps.rackspace.com> Date: Mon, 2 May 2016 17:03:48 +0300 Message-ID: From: Roman Yeryomin To: dpreed@reed.com Cc: Dave Taht , make-wifi-fast@lists.bufferbloat.net, Ben Greear , "codel@lists.bufferbloat.net" , ath10k Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] fq_codel_drop 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: Mon, 02 May 2016 14:03:49 -0000 On 1 May 2016 at 17:47, wrote: > Maybe I missed something, but why is it important to optimize for a UDP f= lood? We don't need to optimize it to UDP but UDP is used e.g. by torrents to achieve higher throughput and used a lot in general. And, again, in this case TCP is broken too (750Mbps down to 550), so it's not like Dave is saying that UDP test is broken, fq_codel is just too hungry for CPU > A general observation of control theory is that there is almost always an= adversarial strategy that will destroy any control regime. Sometimes one h= as to invoke an "oracle" that knows the state of the control system at all = times to get there. > > So a handwave is that *there is always a DDoS that will work* no matter h= ow clever you are. > > And 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 controls that can't possibly solve all possible attacks = - i.e. Security Theater. We don't want "anti-DDoS theater" I don't think. > > There is an alternative mechanism that has been effective at dealing with= DDoS in general - track the disruption back to the source and kill it. (t= his is what the end-to-end argument would be: don't try to solve a fundamen= tally end-to-end problem, DDoS, solely in the network [switches], since you= have to solve it at the edges anyway. Just include in the network things t= hat will help you solve it at the edges - traceback tools that work fast an= d targeted shutdown of sources). > > I don't happen to know of a "normal" application that benefits from UDP f= looding - not even "gossip protocols" do that! > > In context, then, let's not focus on UDP flood performance (or any other = "extreme case" that just seems fun to work on in a research paper because i= t is easy to state compared to the real world) too much. > > I know that the reaction to this post will be to read it and pretty much = go on as usual focusing on UDP floods. But I have to try. There are so many= more important issues (like understanding how to use congestion signalling= in gossip protocols, gaming, or live AV conferencing better, as some relat= ed examples, which are end-to-end problems for which queue management and c= ongestion signalling are truly crucial). > > > > On Sunday, May 1, 2016 1:23am, "Dave Taht" said: > >> On Sat, Apr 30, 2016 at 10:08 PM, Ben Greear w= rote: >>> >>> >>> On 04/30/2016 08:41 PM, Dave Taht wrote: >>>> >>>> There were a few things on this thread that went by, and I wasn't on >>>> the ath10k list >>>> >>>> (https://www.mail-archive.com/ath10k@lists.infradead.org/msg04461.html= ) >>>> >>>> first up, udp flood... >>>> >>>>>>> From: ath10k on behalf of Roma= n >>>>>>> Yeryomin >>>>>>> Sent: Friday, April 8, 2016 8:14 PM >>>>>>> To: ath10k@lists.infradead.org >>>>>>> Subject: ath10k performance, master branch from 20160407 >>>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> I've seen performance patches were commited so I've decided to give= it >>>>>>> a try (using 4.1 kernel and backports). >>>>>>> The results are quite disappointing: TCP download (client pov) drop= ped >>>>>>> from 750Mbps to ~550 and UDP shows completely weird behavour - if >>>>>>> generating 900Mbps it gives 30Mbps max, if generating 300Mbps it gi= ves >>>>>>> 250Mbps, before (latest official backports release from January) I = was >>>>>>> able to get 900Mbps. >>>>>>> Hardware is basically ap152 + qca988x 3x3. >>>>>>> When running perf top I see that fq_codel_drop eats a lot of cpu. >>>>>>> Here is the output when running iperf3 UDP test: >>>>>>> >>>>>>> 45.78% [kernel] [k] fq_codel_drop >>>>>>> 3.05% [kernel] [k] ag71xx_poll >>>>>>> 2.18% [kernel] [k] skb_release_data >>>>>>> 2.01% [kernel] [k] r4k_dma_cache_inv >>>> >>>> >>>> The udp flood behavior is not "weird". The test is wrong. It is so >>>> filling >>>> the local queue as to dramatically exceed the bandwidth on the link. >>> >>> >>> It would be nice if you could provide backpressure so that you could >>> simply select on the udp socket and use that to know when you can send >>> more frames?? >> >> The qdisc version returns NET_XMIT_CN to the upper layers of the >> stack in the case >> where the dropped packet's flow =3D the ingress packet's flow, but that >> is after the >> exhaustive search... >> >> I don't know what effect (if any) that had on udp sockets. Hmm... will >> look. Eric would "just know". >> >> That might provide more backpressure in the local scenario. SO_SND_BUF >> should interact with this stuff in some sane way... >> >> ... but over the wire from a test driver box elsewhere, tho, aside >> from ethernet flow control itself, where enabled, no. >> >> ... but in that case you have a much lower inbound/outbound >> performance disparity in the general case to start with... which can >> still be quite high... >> >>> >>> Any idea how that works with codel? >> >> Beautifully. >> >> For responsive TCP flows. It immediately reduces the window without a RT= T. >> >>> Thanks, >>> Ben >>> >>> -- >>> Ben Greear >>> Candela Technologies Inc http://www.candelatech.com >> >> >> >> -- >> Dave T=C3=A4ht >> Let's go make home routers and wifi faster! With better software! >> http://blog.cerowrt.org >> _______________________________________________ >> Make-wifi-fast mailing list >> Make-wifi-fast@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast >> > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast