From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A7B643B2A4 for ; Thu, 29 Nov 2018 02:22:41 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 1A35121B1A; Thu, 29 Nov 2018 07:22:39 +0000 (UTC) From: Dave Taht To: "Bless\, Roland \(TM\)" Cc: Luca Muscariello , Dave Taht , Jonathan Morton , bloat References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <2d70516d-cbb3-bd77-f3d2-a8dc1bf661ec@kit.edu> Date: Wed, 28 Nov 2018 23:22:28 -0800 In-Reply-To: <2d70516d-cbb3-bd77-f3d2-a8dc1bf661ec@kit.edu> (Roland Bless's message of "Wed, 28 Nov 2018 13:10:02 +0100") Message-ID: <87mupswdor.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 29 Nov 2018 07:22:41 -0000 "Bless, Roland (TM)" writes: > Hi Luca, > > Am 28.11.18 um 11:48 schrieb Luca Muscariello: > >> And for BBR, I would say that one thing is the design principles another >> is the implementations >> and we better distinguish between them. The key design principles are >> all valid. > > While the goal is certainly right to operate around the optimal point > where the buffer is nearly empty, BBR's model is only valid from either > the viewpoint of the bottleneck or that of a single sender. I think I agree with this, from my own experimental data. > > In BBR, one of the key design principle is to observe the > achieved delivery rate. One assumption in BBRv1 is that if the delivery > rate can still be increased, then the bottleneck isn't saturated. This > doesn't necessarily hold if you have multiple BBR flows present at the > bottleneck. > Every BBR flow can (nearly always) increase its delivery rate while > probing: it will simply decrease other flows' shares. This is not > an _implementation_ issue of BBRv1 and has been explained in section III > of our BBR evaluation paper. Haven't re-read it yet. > > This section shows also that BBRv1 will (by concept) increase its amount > of inflight data to the maximum of 2 * estimated_BDP if multiple flows > are present. A BBR sender could also use packet loss or RTT increase as Carnage! > indicators that it is probably operating right from the optimal > point, but this is not done in BBRv1. > BBRv2 will be thus an improvement over BBRv1 in several ways. I really really really want a sane response to ecn in bbr. > > Regards, > Roland > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat