From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CB1F53B29E for ; Tue, 27 Nov 2018 05:50:25 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6AF2BB9; Tue, 27 Nov 2018 11:50:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543315824; bh=8KkuJKz1Ai5TolaquP8g9qzFRd2lNvc/gzi3pXOi+n0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=xi+f2Y99lemRvf2XS/KLxvvMRKhep5gteGjNNAcHBcORRU3hBtrsSF0cgJSShHTIu LT0eIYTaDI/Y6OPPznJcek8+U4ffMDQwcKYjGFq2lS9+uVssBCoVjUDf4GOpUFPL0D gbNVkwvc+qTS7/UgUTBPDzEKFKnWO0Bdkz6LSNtA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 68DE89F; Tue, 27 Nov 2018 11:50:24 +0100 (CET) Date: Tue, 27 Nov 2018 11:50:24 +0100 (CET) From: Mikael Abrahamsson To: Luca Muscariello cc: "Bless, Roland (TM)" , Jonathan Morton , bloat In-Reply-To: Message-ID: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <86b16a95-e47d-896b-9d43-69c65c52afc7@kit.edu> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Bloat] when does the CoDel part of fq_codel help in the real world? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 10:50:26 -0000 On Tue, 27 Nov 2018, Luca Muscariello wrote: > link fully utilized is defined as Q>0 unless you don't include the > packet currently being transmitted. I do, so the TXtteer is never idle. > But that's a detail. As someone who works with moving packets, it's perplexing to me to interact with transport peeps who seem enormously focused on "goodput". My personal opinion is that most people would be better off with 80% of their available bandwidth being in use without any noticable buffer induced delay, as opposed to the transport protocol doing its damndest to fill up the link to 100% and sometimes failing and inducing delay instead. Could someone perhaps comment on the thinking in the transport protocol design "crowd" when it comes to this? -- Mikael Abrahamsson email: swmike@swm.pp.se