From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 44D823B260 for ; Fri, 6 May 2016 03:50:32 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u467oLJl011445; Fri, 6 May 2016 00:50:21 -0700 Date: Fri, 6 May 2016 00:50:21 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Kevin Darbyshire-Bryant cc: cake@lists.bufferbloat.net In-Reply-To: <0eca51dc-694b-6a85-d56d-1ed19e9fc2ef@darbyshire-bryant.me.uk> Message-ID: References: <0eca51dc-694b-6a85-d56d-1ed19e9fc2ef@darbyshire-bryant.me.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII 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:50:32 -0000 On Fri, 6 May 2016, 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 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. If it can be done, this would not be a case of dropping packets, but rather blocking the write to the network. my (semi-informed) knee-jerk reaction is that this would be expensive to signal, so not something to do for the normal case, but possibly something worth doing in the elephant-flow situation as it could slow a local sender down faster than dropping packets and waiting for feedback to signal it to slow down. David Lang