From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4C23C21F383 for ; Tue, 3 Nov 2015 05:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446559013; bh=ADqDDgHQoAYXHBklAYDtvv60BClaNco5JMW3ozgpg9c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=eQ1igkjtNvmaH+Hk2Qjll1dbxnBjDciTAG9yrDq6H2+JcHdOewddFFU3IjS8SwdR6 WwrrMnrSGlRQSN9TzKMluRjlp7VIq4ZAfY6AnELC3eLJIImaYXi6IdCtu3lKYvtpzz GZcfFhYEEEKpRDjRYlT3xh8EgrfB7etou8Fo29sY= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id AB64FC402C3; Tue, 3 Nov 2015 14:56:52 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <5638A4F4.2010701@darbyshire-bryant.me.uk> <87si4nntcg.fsf@toke.dk> <0196FDEC-50A7-4ECA-9973-1FD23FF2945A@gmx.de> Date: Tue, 03 Nov 2015 14:56:52 +0100 In-Reply-To: <0196FDEC-50A7-4ECA-9973-1FD23FF2945A@gmx.de> (Sebastian Moeller's message of "Tue, 3 Nov 2015 14:49:43 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877flznq3f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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:57:20 -0000 Sebastian Moeller writes: > 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. Yes, that is exactly it. But that happens when the packet at the head of the queue is waiting on the packet *before* it, which will be in a lower layer in the process of being transferred (at low bandwidths that "lower layer" has in practice been HTB). However, now that cake itself is doing the delaying (via the packet transmission scheduling), this is not as clear-cut. The actual packet at the head of the queue is now the one being delayed. I'm afraid I don't quite grok how the shaper and CoDel interacts in this case; guess I'll go read the code. > 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... That is also a (separate IMO) issue; however, as Dave said, we need to be vary of just assuming that the VoIP queue will be only small VoIP packets: there's no admission control! -Toke