From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 486363CB38 for ; Mon, 3 Apr 2023 00:27:17 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id DF5FE18264F; Sun, 2 Apr 2023 21:27:15 -0700 (PDT) Date: Sun, 2 Apr 2023 21:27:15 -0700 (PDT) From: David Lang To: Ayush Mishra cc: Neal Cardwell , BBR Development , ayush@comp.nus.edu.sg, bloat In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============7104330276760803825==" Subject: Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet? 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: Mon, 03 Apr 2023 04:27:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============7104330276760803825== Content-Type: text/plain; format=flowed; charset=US-ASCII On Mon, 3 Apr 2023, Ayush Mishra via Bloat wrote: > ==> I agree too. But I think one of the key challenges here could be when > the dynamically entering flows are extremely tiny (which I imagine is quite > common). In those cases, there is a possibility that by the time the > long-running flow backs off, the congestion it was responding to has > already ended because the tiny flows have exited the bottleneck (think > microbursts caused by flows that last 1-2 RTTs). In a perfect world we'd > like to deal with elephant and mice flows in isolation at the switch, but > there are likely things we can do from the endpoint too. Maybe some kind of > a two-phase backoff, with the second phase only kicking in after a period > of hysteresis to make sure it's responding to persistent congestion and not > just brief microbursts. This is just off the top of my head, so I'm not > sure how something like this would play out in the overall dynamics and > convergence of the algorithm that implements it. if the backoff is less drastic than currently, I would say that it's reasonable to have the elephant back off for congestion caused by a microburst, as such bursts are not uncommon, and while the one that triggered the backoff may finish before the backoff happens, it's made room for the next one. David Lang --===============7104330276760803825== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: <06133n02-486r-9pno-46n3-p97s7703p95o@ynat.uz> Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQmxvYXQgbWFp bGluZyBsaXN0CkJsb2F0QGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3RzLmJ1ZmZl cmJsb2F0Lm5ldC9saXN0aW5mby9ibG9hdAo= --===============7104330276760803825==--