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 6D2A521F3F7; Thu, 16 Apr 2015 04:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk Sender: toke@toke.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1429185054; bh=HCEHHkfZ2LshqlFQsFWMqN94DzOgCrwr6G5zfKb4PXE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Zy0OjH1HlAJ0q0Tf5m16Zhl9BbBeh49yQA3A4Xs5tEmKxOveKFwPOcaHvcIbZVD4f G8PnYf7rFqgL5Rc0K2Z2nB+g4QRhl19VHczz93jO2cdiwM3ahAzoLS4Ysas2RxYHHz rFfrzGeLLSkA7QbT1R3IOIsdar1nPXTSIJidm4+M= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 55352C4023D; Thu, 16 Apr 2015 13:50:53 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Rich Brown References: Date: Thu, 16 Apr 2015 13:50:53 +0200 In-Reply-To: (Rich Brown's message of "Thu, 16 Apr 2015 00:25:01 -0400") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87twwg5m1u.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" Subject: Re: [Codel] [Cake] hard limit codel X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 11:51:30 -0000 Rich Brown writes: > Please don't fisk this. The paper is *way* too long to be worth a > sentence-by-sentence refutation of every inaccuracy or outright > wrong-headed understanding of Codel... :-) I think this paragraph pretty much sums it up: "Actually, the throughput of hard limit CoDel is signifi- cantly lower than the original CoDel only when the RTT is large (500ms), the bandwidth is high (64 Mbps) with only one TCP flow, in which case the throughput is only 4.1 Mbps, 63% lower than that of the original CoDel. Though it may seem to be a significant loss, we argue that it is acceptable because even in the worst case, a bit rate of 4 Mbps is sufficient to support today=E2=80=99s 720p videos. The link utilization is = much higher when either of the three conditions changes." Surely, 4Mbps is enough for everybody? I'll add, though, that I have seen the sentiment expressed here ("we need to limit the max delay of CoDel") in other contexts. And, well, delay spikes *is* a problem! -Toke