From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0055.outbound.protection.outlook.com [157.55.234.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C0C023B260 for ; Fri, 6 May 2016 03:29:09 -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=lP5lHSd4uCUrhUhP3jEn7+JXnM8BbpcSShwBjeCXebg=; b=ePQmTJiERfh6cu15azHxULJEYeuDy5Z3ZH8fEtR+CV15IybP78TQQ+O+mab3Dm9XKq9ROOVixPxuqBO+eVVF5Z1F1yekTAZ5654fAzPHqy8FkfBkuZozjmWoZSrzAOkGHQC3Q6umv5EuWSyuW93/JG2S8O19RdIXUNCXI6nnvHM= Authentication-Results: lists.bufferbloat.net; dkim=none (message not signed) header.d=none; lists.bufferbloat.net; dmarc=none action=none header.from=darbyshire-bryant.me.uk; Received: from [192.168.100.126] (78.40.158.54) by DB5PR07MB0934.eurprd07.prod.outlook.com (10.161.200.141) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 6 May 2016 07:29:05 +0000 To: From: Kevin Darbyshire-Bryant Message-ID: <0eca51dc-694b-6a85-d56d-1ed19e9fc2ef@darbyshire-bryant.me.uk> Date: Fri, 6 May 2016 08:29:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8670FE653E2C0802C2442B89" X-Originating-IP: [78.40.158.54] X-ClientProxiedBy: DB4PR03CA0010.eurprd03.prod.outlook.com (10.160.39.148) To DB5PR07MB0934.eurprd07.prod.outlook.com (10.161.200.141) X-MS-Office365-Filtering-Correlation-Id: 9b22e5ee-0cb7-40e6-68ae-08d375801c35 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0934; 2:MvxQR/+kvPzMv38RvTCajcZV4yUWtnf5AWMjMJzm141amsjkQ3n9qB7Tvq5yLkfxzlVjzgEL1IykqsVDjU+P2t80ya5T79QhmTtyWH1bJE2DJi29N1jbYLiz3Eg+mzLNERZJypICQZoN/wnyDmY+7X8xPdkWVxqFN24UL25Gy5WEIvVC+KyBopDctcvw4BsA; 3:QCj+QmbU/QsqZdcN8399CKF8QyH9nDbG0QubhLHwnpeajGxeH61l5JAkelw64LTkEe7/0NkTxU1GaD+1eg+0VofPpUiaMg5lsnFV7Jsr2Q53oGoaaoXuXSzbCHpCqTqp X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB0934; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0934; 25:S8deJys/OYlL6MGp3mgBdfPWl6+B36dEeleOjFEAssLgrUrn+bxQYrnAhJtte1UHGNH96dcC0eBELUNESAVoFx7y4GkJqUXbK+59pmTcbippFjGizaYWzLV15lgaIz+JY87fdOYGpo+JVq/hXjBE27wIHaPJ7o36Q8iRoQ6r9vY3xBEEhuwE5uVa0majcPdNvUs+ROatml7knHOLcbQqjCJN46gGUy/r7KBrVXSS+Rveb3o/MFD7/gh1GNVR515VGUNrTUAvzfEoxo4cfbRvDrRTBqgGF9gS9an167MxquH2hiFfrzxh1UgB2Urf3e2kqRzsv98S7JfYZYJkgIn1hBQDhYzFQDR2LPg0hCajumNKoL1qhaavMKmF/6FJhPmrlvmngrnKT6nOVWPXXKwK75LxmjMjyf4PHr2i51R1SLon8FMqycMi3FJrePcQdls9KrFrxcPQozGZaM+VK+aNhCrusqyB3UwpgNvAEXA9Iw7F9hqySgUqnWZkT0qeAfj94Fi4C+o+cEDuwnrau4rS07+9EzFUIkMfDoNPrA7dTDWX4w5YBhAzDCuVyxT8rJXodmkmG6P4KfukSBZJrxcr+t7MZJH36YUoGSrLL+Vl6HErx5k6N9QbMHgMOUtfPa47GjCpFx6I3+FSNbm07WsxWJ3gMQPp/dC/3gH42JBN6fr6sZWiJ6Mas5YJM7Wj7e+9MzhNAD0Szq5WURMArhzzlLPEZ2UDLFXjf23TfEHAeS/XNWBqaHeiG4XOQi9a7XS9g1qKdy1d0aGblvqWFsEFVXZcOWAH4Zx90kPEOxqq7K/01mf7kjob9wvB6DAXUxRFxYURaX1xafpfv0ezrLRNJw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046); SRVR:DB5PR07MB0934; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB0934; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0934; 4:dTTJghLdv19Dk36DcSIA5vuagFUGFIpuwPUkwvCUeer7MLBCffBh2fQanTK0rEGKMxYpS+cPiVHng+lxArRen3Ij/uGg1S0P2ayEGsfQlVAb969JoPp+LIBsryG/sRFApluOvvFSQEYlRo6EV5zNCdSSrC41JVtZdCYJbWKsP1AV1vURZHnL1L/wEZcDAL3a0Jw4MoTSyoDqEo5DNCcz3OjvqOajI/cZsQaK4WwPe5jRLdVZgj9KnZcTAuEDXTkdezVaICQyucg9pcKbfIsu0HsnafD9n4/6/+tHcfk7AFwYEQUczc+1KmAeN/wndfzw1wR/DBnkcMaFlusMUzJq+jmKlyBD781zwrHzgK0Kv7ghim+aA0Z15otqgeNOdf3ZsvYOqWoLLxX1CHJArZgQ2stF5tKs29XzZCsCtnZvCz8= X-Forefront-PRVS: 09347618C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(53754006)(5004730100002)(2906002)(110136002)(107886002)(86362001)(81166005)(54356999)(50986999)(97736004)(4001350100001)(92566002)(19580395003)(270700001)(19580405001)(6116002)(3846002)(586003)(65806001)(65956001)(189998001)(66066001)(84326002)(83506001)(5008740100001)(42186005)(36756003)(16236675004)(77096005)(31686004)(2351001)(229853001)(33646002)(74482002)(512874002)(117156001)(450100001)(64126003)(31696002)(65826006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0934; H:[192.168.100.126]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR07MB0934; 23:U5Y8j9unsJITQXIMJkxaYANlo0oqKj0NUSM4YLSoq?= =?us-ascii?Q?vKQcxmWgB2CwKXI1XDvlfD9q/Fddb19p9LXJSw6a8Xpt/Xhcnd0D/8Mgk/8+?= =?us-ascii?Q?pNSwep8XMFCWDTjdkM9hmah1bOsrjgLyp1Lw1zwvXClgF0EH+NMUb4upvnrR?= =?us-ascii?Q?P6CZkGmgJJmPJr7swwcYJUQ+OJCfp+iSAWBvOOrHwGfJqK+DBu107qvHzyqS?= =?us-ascii?Q?/bNczBIpjwNxbAtKQ2o5nSLj1yRC59o7Qe/bj6jjvWcm8KDpUFxOBzwsj96z?= =?us-ascii?Q?J/lJOdAXfbxeL0U7hGjt2HmcbKLSUsQoIlNGpgQcYxXTGhbuvHJ1lCHfCuzG?= =?us-ascii?Q?eD3unl8Y62gf9Mgjj8dkBytLddfu0Zl42VO5Levu8m1qlyxKJCZt4gxA86WQ?= =?us-ascii?Q?O1ACmIZI4UcYLyyEHRcivWEgLgggMm5XJ/yb8DbeSVw5Ayjg5VuqeRcJqlkZ?= =?us-ascii?Q?Z4qScsFnYRXlEL1rUcdqhehTMbWllNfBh8mjKVz82O3nHmbRL72JgyRg0XlJ?= =?us-ascii?Q?eHWUIHSiqW8dgIHFa0ZG/gWn6VHmB2DrmCfhG5kY4BZ6CrWRYhN6NEQgP7c9?= =?us-ascii?Q?hA3coPBc+pVokQ8kzwHNAZTUjrNBnfCmBp2OOme41ELhvuIR752TWTUTaSw/?= =?us-ascii?Q?CJwU5DMsie47XO3OnOpGVPAWyKoVWTUTPrP01+7r+ERNtpAKomUSKtDXop8J?= =?us-ascii?Q?1L63zUkU8bm68GzS/wwYcqQt5w2qbjh6hZ81zhrmGQ4boLPcLnfLlhbXBf2W?= =?us-ascii?Q?uNIJ00x2ox/09p73FYuAIVurichskj3Az3IEf6VsS9xATTgNUtC7eeXUXcAd?= =?us-ascii?Q?kFvoBrKKEmRH7n/QbC55rLBpuP9NZiidUhB9O7mGT41sq0Zlf07iAO6A/qw1?= =?us-ascii?Q?jFggeXPaQW9mn+hY6KhBbKy1vol3Xjni4vmSWyM175NARKYMu9oW0f8S6WfG?= =?us-ascii?Q?xjMQPa7Coiuvz7SngUZUJeWFVOh5cT33zTfBeIoRG04Sdct6DLeTQDgOEFff?= =?us-ascii?Q?OjAnmRq862ZBl+auwgYOEM0/j3wYhtmSt5R5tAs89G9CtxGN7gWpSfY1TU+O?= =?us-ascii?Q?A43UXEIZEHmDpsCE2WwCBClTaPY9PCRkQgZL5RAdX9mP8ZobfTrapoXoalfi?= =?us-ascii?Q?F07Qs0CP58=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0934; 5:c81dfq2W6gZp4hJKEW0FrY3MrJ9QX9aV/+xXNjnQ8QSL2Is2x2DaLtdk67SpFOa0JUVcKwgT3Lu2VriBwubLgLz1R3TlU3SLFjy/b8H4pT4ts9Ha2yF59d/iBHWBOtzToGrm1hldy+5zGmbtOgQ6Ow==; 24:Yk0Ody6UpVg6f2HiIVITDo/7MwBchk2MYmXMgPeniYbLr3adj2z8G94dXegDo8c2s+jRzKb34rctjpnOiV7q9BwY+81wSQpv4spF0aCKwQI=; 7:PqC5TIx3VlYJoOrPDIV1+gAko2mFpDM1e3wFyAyCrd5Iv+czDYojJZwtcOcqajtWOBRIF3A2Ph92UbtWPYGwrazXRsIViGgwLNPSEnwBIsy9OSBD16rrfaOWxavKAAA20qbupCpfpt5vAkan6KwfdDe0cT5gMsLnhz8GF18UETLz02WD0r/huRAnjtFzk5my SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2016 07:29:05.5001 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0934 Subject: [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:29:10 -0000 --------------8670FE653E2C0802C2442B89 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 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 to the stack at that point to (cake already does this signalling when getting to its buffer size limit) Probably a very silly idea. -- Thanks, Kevin@Darbyshire-Bryant.me.uk M: +44 7947 355344 H: +44 1256 478597 --------------8670FE653E2C0802C2442B89 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

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 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 to the stack at that point to (cake already does this signalling when getting to its buffer size limit)


Probably a very silly idea.


-- 
Thanks,

Kevin@Darbyshire-Bryant.me.uk
M: +44 7947 355344 H: +44 1256 478597
--------------8670FE653E2C0802C2442B89--