From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 953783B29E for ; Tue, 27 Nov 2018 06:04:23 -0500 (EST) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRbAD-000EAy-J8; Tue, 27 Nov 2018 12:04:21 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gRbA9-0008em-5Q; Tue, 27 Nov 2018 12:04:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Tue, 27 Nov 2018 12:04:16 +0100 Cc: "Bless, Roland (TM)" , Jonathan Morton , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <86b16a95-e47d-896b-9d43-69c65c52afc7@kit.edu> To: Luca Muscariello X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 55FAB8B81C9B9EBD34BCC280195B627469CB8FEB 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 11:04:23 -0000 Folks, I'm lost in this conversation: I thought it started with a statement = saying that the queue length must be at least a BDP such that full = utilization is attained because the queue never drains. To this, I'd want to add that, in addition to the links from Roland, the = point of ABE is to address exactly that: = https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-12 (in the RFC Editor queue) But now I think you're discussing a BDP worth of data *in flight*, which = is something else. Cheers, Michael > On 27 Nov 2018, at 11:40, Luca Muscariello = wrote: >=20 > OK. We agree. > That's correct, you need *at least* the BDP in flight so that the = bottleneck queue never empties out. >=20 > This can be easily proven using fluid models for any congestion = controlled source no matter if it is=20 > loss-based, delay-based, rate-based, formula-based etc. >=20 > A highly paced source gives you the ability to get as close as = theoretically possible to the BDP+epsilon > as possible. >=20 > 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. >=20 >=20 >=20 > On Tue, Nov 27, 2018 at 11:35 AM Bless, Roland (TM) = wrote: > Hi, >=20 > Am 27.11.18 um 11:29 schrieb Luca Muscariello: > > I have never said that you need to fill the buffer to the max size = to > > get full capacity, which is an absurdity. >=20 > Yes, it's absurd, but that's what today's loss-based CC algorithms do. >=20 > > I said you need at least the BDP so that the queue never empties = out. > > The link is fully utilized IFF the queue is never emptied. >=20 > I was also a bit imprecise: you'll need a BDP in flight, but > you don't need to fill the buffer at all. The latter sentence > is valid only in the direction: queue not empty -> link fully = utilized. >=20 > Regards, > Roland >=20 > >=20 > >=20 > >=20 > > On Tue 27 Nov 2018 at 11:26, Bless, Roland (TM) = > > wrote: > >=20 > > Hi Luca, > >=20 > > Am 27.11.18 um 10:24 schrieb Luca Muscariello: > > > A congestion controlled protocol such as TCP or others, = including > > QUIC, > > > LEDBAT and so on > > > need at least the BDP in the transmission queue to get full = link > > > efficiency, i.e. the queue never empties out. > >=20 > > This is not true. There are congestion control algorithms > > (e.g., TCP LoLa [1] or BBRv2) that can fully utilize the = bottleneck link > > capacity without filling the buffer to its maximum capacity. The = BDP > > rule of thumb basically stems from the older loss-based = congestion > > control variants that profit from the standing queue that they = built > > over time when they detect a loss: > > while they back-off and stop sending, the queue keeps the = bottleneck > > output busy and you'll not see underutilization of the link. = Moreover, > > once you get good loss de-synchronization, the buffer size = requirement > > for multiple long-lived flows decreases. > >=20 > > > This gives rule of thumbs to size buffers which is also very = practical > > > and thanks to flow isolation becomes very accurate. > >=20 > > The positive effect of buffers is merely their role to absorb > > short-term bursts (i.e., mismatch in arrival and departure = rates) > > instead of dropping packets. One does not need a big buffer to > > fully utilize a link (with perfect knowledge you can keep the = link > > saturated even without a single packet waiting in the buffer). > > Furthermore, large buffers (e.g., using the BDP rule of thumb) > > are not useful/practical anymore at very high speed such as 100 = Gbit/s: > > memory is also quite costly at such high speeds... > >=20 > > Regards, > > Roland > >=20 > > [1] M. Hock, F. Neumeister, M. Zitterbart, R. Bless. > > TCP LoLa: Congestion Control for Low Latencies and High = Throughput. > > Local Computer Networks (LCN), 2017 IEEE 42nd Conference on, pp. > > 215-218, Singapore, Singapore, October 2017 > > http://doc.tm.kit.edu/2017-LCN-lola-paper-authors-copy.pdf > >=20 > > > Which is:=20 > > > > > > 1) find a way to keep the number of backlogged flows at a > > reasonable value.=20 > > > This largely depends on the minimum fair rate an application = may > > need in > > > the long term. > > > We discussed a little bit of available mechanisms to achieve = that > > in the > > > literature. > > > > > > 2) fix the largest RTT you want to serve at full utilization = and size > > > the buffer using BDP * N_backlogged. =20 > > > Or the other way round: check how much memory you can use=20 > > > in the router/line card/device and for a fixed N, compute the = largest > > > RTT you can serve at full utilization.=20 > > > > > > 3) there is still some memory to dimension for sparse flows in > > addition > > > to that, but this is not based on BDP.=20 > > > It is just enough to compute the total utilization of sparse = flows and > > > use the same simple model Toke has used=20 > > > to compute the (de)prioritization probability. > > > > > > This procedure would allow to size FQ_codel but also SFQ. > > > It would be interesting to compare the two under this buffer = sizing.=20 > > > It would also be interesting to compare another mechanism that = we have > > > mentioned during the defense > > > which is AFD + a sparse flow queue. Which is, BTW, already > > available in > > > Cisco nexus switches for data centres. > > > > > > I think that the the codel part would still provide the ECN = feature, > > > that all the others cannot have. > > > However the others, the last one especially can be implemented = in > > > silicon with reasonable cost. > >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat