From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E4BB721F4F5 for ; Tue, 3 Nov 2015 05:49:47 -0800 (PST) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MEtba-1ZehSB0KGA-00FzVJ; Tue, 03 Nov 2015 14:49:41 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <87si4nntcg.fsf@toke.dk> Date: Tue, 3 Nov 2015 14:49:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0196FDEC-50A7-4ECA-9973-1FD23FF2945A@gmx.de> References: <5638A4F4.2010701@darbyshire-bryant.me.uk> <87si4nntcg.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:I2hXEG6HCCxW5znFjmJusgm+4zCpDlazNKRaTZP0lsH/iZjLJDR CrP2F5TzFXzRkGc8J/NQLJpmLSnbR+gnTSL1ZEZhQwN4NyXasQrVCsT35juJF0Co7ESGMhI eehow0/vXd1ioAT3n/t/mABKVD2cFFFDCf3XvNjRp9oOuf28Hwp4jfWzOsqRHLMkILas8ud NXAobzlCF3rZ0vg99ohDQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:b8vLf09Asfc=:Pbsbbm+ADHD6uiiWhDQnAy mBK2zQI18jurcHgZpWeBHif4cYj1YnCPRMDaevaReAJ3T8UMXToXFn01s65YNybiaAAh8l9t9 gFYAF89x9dHSptDyY0VfEF3622m2c8gfCXN5ST2k8kOVuGgR7Q0uJe5jW+wxLfES8acWRhxMu 4mPn7O1YCfT6RUq1JWN19gTePYueQyjhePYKnAJEmFizjMUMYlwvaxa8/JdjCBVDBI2q0HdNR oXLBYPxQmw8Kz4/2n04IRjMd7H90xtNyiiLpblB9hJ4G+Oe0mfiLo6jMTl6RDKnqIq8Mv2gwG IAcCH4TL3dh8yK2QHYfLZddITfSvWfFqQyrYHaa+QXmwLf3T7ll/zGaLMvSt31h/EZgBNUATo rZIL38VaeXTQaMYPddn1zJ3M5A7unFbWxuK9go/JAOsqHrzyI9+s+SYKrl0TorWJBntn5fqG/ lHgIWCxqWd3yKnNQbmc7/GpJy1Fmmq8LpZux1FpUejwKnnfTqj+YUCp1IydWiZV1QN1GVa2Dg TpZj9bTY2RzMWWI0B9+puP0Ml5zEWGLnGObT9afhZjgdI/CEaO3yzsqe1ld55BeBw0I1E7K9J NVozdzJKP5Uub3OqtCCpJPt8NZYWyOyH9Z/YaiHZ9IbCnENtYGP9+VMEcVz/kAR5NKVvrC29X 0XWhuXO6hYFVDBt812GmHSG5zPiLiAcoi7V18YguQciUw0KjuwS7ru2XOI74efiklLNucsR4h jClb75+SrJxa960A7A+87yoSFFtI9CN1Y5M6qntvnCrmneqQ9yYo8830v/2Lpt3aNd3iHDonc s4M0RZM Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More on 'target' corner cases - rate/target/interval confusion? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 13:50:10 -0000 On Nov 3, 2015, at 13:46 , Toke H=F8iland-J=F8rgensen = wrote: > [...] > Now whether or not this is *correct* I'm not so sure about. The = minimum > value set from the MTU is the Linux counterpart to the CoDel NS2 = model's > "always keep one packet in the queue". The reasoning is, basically, = that > there will be at least one packet in the layers below the qdisc which > we will have to wait for before we can dequeue; so CoDel shouldn't = react > until queueing time goes *above* this minimum of waiting for one = packet. > [...] I thought the rationale was that a target be tow the transfer time for a = single MTU packet is not too reasonable as the queue will enter dropping = state for each (full MTU) packet transferred. But that could be me = misunderstanding codel=85 I guess most VoIP packets will not be full = MTU, so on a dedicated VoIP queue the 1.5 * full MTU idea might be = sub-optimal... Best Regards Sebastian=