From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0078.outbound.protection.outlook.com [104.47.1.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2B5BA3B260 for ; Fri, 6 May 2016 03:48:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=darbyshire-bryant.me.uk; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GKns59qGCoJnmMPEG5bjZ2kpDOFhM9wlyk2L8EMMKN0=; b=durfnQ2/WvgGJljpGqo2VmcjNpp89CBh09GnP++HHue9f5GzmHY4quOzVkOCV2J7Dfc/vS3q362FH8re+tEE7h80ezz4xYv/FsPA9aKSlwKV7f2E+ccLsbwntE+NPQp+UIBZ/QJvuf0QU9+QSpcOubPIn61/KpmzKcEVcAUfHm4= Received: from HE1PR07MB0937.eurprd07.prod.outlook.com (10.162.27.143) by HE1PR07MB0940.eurprd07.prod.outlook.com (10.162.27.146) with Microsoft SMTP Server (TLS) id 15.1.485.9; Fri, 6 May 2016 07:48:45 +0000 Received: from HE1PR07MB0937.eurprd07.prod.outlook.com ([10.162.27.143]) by HE1PR07MB0937.eurprd07.prod.outlook.com ([10.162.27.143]) with mapi id 15.01.0477.017; Fri, 6 May 2016 07:48:45 +0000 From: Kevin Darbyshire-Bryant To: Dave Taht CC: "cake@lists.bufferbloat.net" Thread-Topic: [Cake] UDP floods and taking advantage of egress signalling at ingress Thread-Index: AQHRp2j6YXkSb13jtU2VceDCiCosHp+rheKAgAACus4= Date: Fri, 6 May 2016 07:48:45 +0000 Message-ID: References: <0eca51dc-694b-6a85-d56d-1ed19e9fc2ef@darbyshire-bryant.me.uk>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=darbyshire-bryant.me.uk; x-originating-ip: [78.40.158.54] x-ms-office365-filtering-correlation-id: ede871ef-c2b9-4133-e034-08d37582da4b x-microsoft-exchange-diagnostics: 1; HE1PR07MB0940; 5:nuGEeUnWXBb5pXPwXHJRvWUg8Vl3IEyQ+O7XoFrHT3be/gIAt47dvSskM0Ie7GsCW+Xk7IZ+gCr713Y6R4nK5fsePPlZvSmxKR/bUoGgfJmjg6CTKhKW0oihYnfkdNIRF5KKJcG08xiU7VFnUBZLNQ==; 24:MCe4LCPLtz128GVtdNhqWOVqRf6zX0iu5mK5nqwSGZ1lTLyH8MMSxnggHM3sU+jx2oj60fZuoN31l7jSxZAOnfX4uzPXNxFRwwQNt5HFM8k=; 7:7oUbN/d4m0u+Ueg9Fk2MO5HdH9q2fcVWgjPynd+utBr1aSCtvlyQRbcoW2O00VvfukFrztwE9QMBVk9LtaqP5Xug2bn65pb8LraKq7RovWC0sH7SwnmFg2rV5Kmu9q0Bd3hzbUTrnlvwCySdDQgO05VC9GHlHtnGE3E5r4Wshsdb44NN3TrTRNEg6V5AGleH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0940; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:HE1PR07MB0940; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0940; x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(53754006)(3660700001)(1220700001)(19617315012)(3846002)(102836003)(6116002)(74482002)(3280700002)(106116001)(92566002)(586003)(5008740100001)(10400500002)(33656002)(16236675004)(2950100001)(2900100001)(66066001)(122556002)(5002640100001)(86362001)(54356999)(76176999)(50986999)(81166005)(36756003)(11100500001)(4326007)(189998001)(19580405001)(8936002)(82746002)(87936001)(2906002)(15975445007)(77096005)(19580395003)(5004730100002)(110136002)(83716003)(16601075003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0940; H:HE1PR07MB0937.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A76B786F7E6D4315BF2D83F70CC4B1C0darbyshirebryantmeuk_" MIME-Version: 1.0 X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2016 07:48:45.2819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9151708b-c553-406f-8e56-694f435154a4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0940 Subject: Re: [Cake] UDP floods and taking advantage of egress signalling at ingress X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:48:48 -0000 --_000_A76B786F7E6D4315BF2D83F70CC4B1C0darbyshirebryantmeuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My asleep brain is better than the awake one :-) Tcp in essence self servos into equilibrium, udp flows (floods) potentially= don't. If the protocol doesn't servo then something else should, ideally b= efore buffer full/memory issues make that happen anyway. Anyway time to switch brain to dayjob mode :-) -- Cheers, Kevin@Darbyshire-Bryant.me.uk Sent from my phone, apologies for brevity, spelling & top posting On 6 May 2016, at 08:39, Dave Taht > wrote: On Fri, May 6, 2016 at 12:29 AM, Kevin Darbyshire-Bryant > wrote= : Hi All, My brain woke up with this idea rattling around in it this morning...obviously the subconscious has been busy. So here it is: Is there any way to use the egress drop signalling at ingress time to drop stuff before it gets into the queue so then we don't have to drop it at egress? Something like: At enqueue if we've a matching flow check to see if that flow had been in egress 'fast dropping' state *and* know how much data in terms of time it had to fast drop to get the queue back under the nominal time threshold. If say it had to drop 10ms worth of packets to get back to the nominal 5ms threshold then it dropped 67% of the packets/data. I'd lik= e to think of that as an 'unresponsive flow'...hence could it be possible to use that information at ingress time and in essence drop (some? 66%?) of them there, we can also signal congestion to the stack at that point to (cake already does this signalling when getting to its buffer size limit) Probably a very silly idea. No, actualy, I'd been thinking about the same thing myself for days. :) I've always wanted a way to notify userspace that I was dropping (the heck out of) something on egress to try and stuff it up on ingress, or do something more intelligent like re-route the traffic elsewhere. There was a lot of talk about adding the ability to drop stuff really fast in the rx ring recently using the jit BPF stuff. I was at a meeting where tom herbert talked about that, and I confess, extremely dubious. Then... well, I see lots of drops on ingress already I don't want, the udp flooding episode made me go look harder at whole system behavior... and I can't find the lwn article about it. -- Thanks, Kevin@Darbyshire-Bryant.me.uk M: +44 7947 355344 H: +44 1256 478597 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake -- Dave T?ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org --_000_A76B786F7E6D4315BF2D83F70CC4B1C0darbyshirebryantmeuk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
My asleep brain is better than the awake one :-)

Tcp in essence self servos into equilibrium,= udp flows (floods) potentially don't. If the protocol doesn't servo then s= omething else should, ideally before buffer full/memory issues make that ha= ppen anyway. 

Anyway time to switch brain to dayjob mode := -)


= --
Cheers,

Sent from my= phone, apologies for brevity, spelling & top posting

On 6 May 2016, at 08:39, Dave Taht <dave.taht@gmail.com> wrote:

On Fri, May 6, 2016 at 12:29 AM, Kevin Darbyshire-Bryant<= br> <kevin@darbyshire= -bryant.me.uk> wrote:
Hi All,

My brain woke up with this idea rattling ar= ound in it this
morning...obviously the subconscious has be= en busy.  So here it is:

Is there any way to use the egress drop sig= nalling at ingress time to drop
stuff before it gets into the queue so then= we don't have to drop it at
egress?

Something like: At enqueue if we've a match= ing flow check to see if that
flow had been in egress 'fast dropping' sta= te *and* know how much data in
terms of time it had to fast drop to get th= e queue back under the nominal
time threshold.  If say it had to drop= 10ms worth of packets to get back to
the nominal 5ms threshold then it dropped 6= 7% of the packets/data.  I'd like
to think of that as an 'unresponsive flow'.= ..hence could it be possible to
use that information at ingress time and in= essence drop (some? 66%?) of
them there, we can also signal congestion t= o the stack at that point to
(cake already does this signalling when get= ting to its buffer size limit)


Probably a very silly idea.

No, actualy, I'd been thinking about the same thing myself for days.<= /span>
:) I've always wanted a way to notify userspace that I was dropping
(the heck out of) something on egress to try and stuff it up on
ingress, or do something more intelligent like re-route the traffic
elsewhere.

There was a lot of talk about adding the ability to drop stuff really=
fast in the rx ring recently using the jit BPF stuff.

I was at a meeting where tom herbert talked about that, and I confess= ,
extremely dubious. Then... well, I see lots of drops on ingress
already I don't want, the udp flooding episode made me go look harder=
at whole system behavior...

and I can't find the lwn article about it.



--
Thanks,

Kevin@Darbyshire-Bryant.me.uk
M: +44 7947 355344 H: +44 1256 4785= 97


___________________________________________= ____
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake




--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
--_000_A76B786F7E6D4315BF2D83F70CC4B1C0darbyshirebryantmeuk_--