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 897593B2A4 for ; Thu, 29 Nov 2018 02:21:06 -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 DEB9521B1A; Thu, 29 Nov 2018 07:21:04 +0000 (UTC) From: Dave Taht To: Luca Muscariello Cc: Dave Taht , Jonathan Morton , bloat References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> Date: Wed, 28 Nov 2018 23:20:53 -0800 In-Reply-To: (Luca Muscariello's message of "Wed, 28 Nov 2018 11:48:19 +0100") Message-ID: <87r2f4wdre.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:21:06 -0000 Luca Muscariello writes: > On Wed, Nov 28, 2018 at 11:40 AM Dave Taht > wrote: > > On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello > wrote: > > > > Dave, > > > > The single BDP inflight is a rule of thumb that does not account > for fluctuations of the RTT. > > And I am not talking about random fluctuations and noise. I am > talking about fluctuations > > from a control theoretic point of view to stabilise the system, > e.g. the trajectory of the system variable that > > gets to the optimal point no matter the initial conditions > (Lyapunov). > > I have been trying all day to summon the gumption to make this > argument: > > IF you have a good idea of the actual RTT... > > it is also nearly certain that there will be *at least* one other > flow > you will be competing with... > therefore the fluctuations from every point of view are dominated > by > the interaction between these flows and > the goal is, in general, is not to take up a full BDP for your > single flow. > > And BBR aims for some tiny percentage less than what it thinks it > can > get, when, well, everybody's seen it battle it out with itself and > with cubic. I hand it FQ at the bottleneck link and it works well. > > single flows exist only in the minds of theorists and labs. > > There's a relevant passage worth citing in the kleinrock paper, I > thought (did he write two recently?) that talked about this > problem... > I *swear* when I first read it it had a deeper discussion of the > second sentence below and had two paragraphs that went into the > issues > with multiple flows: > > "ch earlier and led to the Flow Deviation algorithm [28]. 17 The > reason that the early work of 40 years ago took so long to make > its > current impact is because in [31] it was shown that the mechanism > presented in [2] and [3] could not be implemented in a > decentralized > algorithm. This delayed the application of Power until the recent > work > by the Google team in [1] demonstrated that the key elements of > response time and bandwidth could indeed be estimated using a > distributed control loop sliding window spanning approximately 10 > round-trip times." > > but I can't find it today. > > > > Here it is > > https://www.lk.cs.ucla.edu/data/files/Kleinrock/Internet%20Congestion%20Control%20Using%20the%20Power%20Metric-Keep%20the%20Pipe%20Just%20Full%2C%20But%20No%20Fuller%20July%202018.pdf Thank you that is more what I remember reading. That said, I still remember a really two paragraph thing that went into footnote 17 of the 40+ years of history behind all this, that clicked with me about why we're still going wrong... and I can't remember what it is. I'll go deeper into the past and go read more refs off of this.