From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8DEF53B2A4 for ; Sun, 2 Apr 2023 21:49:52 -0400 (EDT) Received: by mail-yb1-xb30.google.com with SMTP id m16so12704993ybk.0 for ; Sun, 02 Apr 2023 18:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680486592; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TmPk3wttQGqJc+GNvVL3t3XZ3Jg91cto0GCl9xOYXUo=; b=D07z12Uh+EihjYPzZgCYB3Iq2GWk4EIXG7+fJXHO3VRxpQKI7EJRtzGeV0AcvJ9hM5 CRfgYL1/CYF62QJxpdppYArJ6nQojly7Q+j99oxCNTTfYI7VGbEbiI3HCUKi33fUgzfZ 637LVi1zhX/U6FjiGgnAev8wwELVpZawJuXC3niOcLYkmv0h7z1l7IjHh/NHSzrJTSk9 trijVC2My1qFXvEvy7YGxlUpadZ1zbfgYjawVjb2mN1rDNiOjfMuWDQol3uNoZhqZmDC aGCeRWjlaHauQj3iDh3o3lntCwsVKqziKc6DcwHpGgfZcGITm6AO72WbThv7F9mGem4t 3Bqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680486592; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TmPk3wttQGqJc+GNvVL3t3XZ3Jg91cto0GCl9xOYXUo=; b=q/EPLirkNGHENewhaXS+NoHTtPhzaiNrY2sEEArhG1yMt5VX84UtmSQmcE6qfGPCO/ IDcZKXMa5HqljljemCbi5lo1vHsIMcHTKmWLB3uDftB1OYvkZNRgnmv2JUyqs/enJEGn 2PO5RDRkWbr0F7zXBECnjMHtrCNePJ0dooDq86FPAJaRdmr5htJXChycXolVvxvuoLzi ixLxY5OIkKQxKdfPfm9h3wfHptmhFm3kSZwNTrv6g+bUZMk9oUWXaO3CWJo0/GRUOkF8 VwtDHEHDL5JRZvcgE8ZDH+ZTNpfx15j0ZeUqlKFBd9fjvJ1FqBYL1REYSzNnT2+Pve/d 0GzA== X-Gm-Message-State: AAQBX9cab2zwGGfZ8Mx157FlLy+RuT4eHTsr+fTG56uDSkVww3WuuH9x mukosconfC7Av3PlYR7Ucq2U4kiz2yhMOPSDl9w= X-Google-Smtp-Source: AKy350b9K9eE3gnXJ0lSFcNoeU2pVh1jkCRvRv+95+ZbHOUvD8lJniDowrda0yTzb9pmQbsqduNHHFnFUuSGgd93m/Y= X-Received: by 2002:a05:6902:1101:b0:b76:126b:5aa1 with SMTP id o1-20020a056902110100b00b76126b5aa1mr18207917ybu.8.1680486591956; Sun, 02 Apr 2023 18:49:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ayush Mishra Date: Mon, 3 Apr 2023 09:49:40 +0800 Message-ID: To: Neal Cardwell Cc: Sebastian Moeller , BBR Development , ayush@comp.nus.edu.sg, bloat Content-Type: multipart/alternative; boundary="0000000000005d0e3005f864c6ed" 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 01:49:52 -0000 --0000000000005d0e3005f864c6ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 2, 2023 at 10:03=E2=80=AFPM Neal Cardwell wrote: > > > On Sun, Apr 2, 2023 at 8:14=E2=80=AFAM Sebastian Moeller wrote: > >> Hi Ayush, >> >> > On Mar 28, 2023, at 11:36, Ayush Mishra via Bloat < >> bloat@lists.bufferbloat.net> wrote: >> > >> > Hey Neal, >> > >> > I was revisiting this thread before presenting this paper in iccrg >> tomorrow - and I was particularly intrigued by one of the motivations yo= u >> mentioned for BBR: >> > >> > "BBR is not trying to maintain a higher throughput than CUBIC in these >> kinds of scenarios with steady-state bulk flows. BBR is trying to be rob= ust >> to the kinds of random packet loss that happen in the real world when th= ere >> are flows dynamically entering/leaving a bottleneck." >> >> But isn't "when there are flows dynamically entering" actually a bona >> fide reason for the already established flows to scale back a bit, to gi= ve >> the new-commers some room to establish themselves? >> > > Yes, I agree that "when there are flows dynamically entering" is actually > a bona fide reason for the already established flows to scale back to giv= e > the newcomers some room to establish themselves. I'm not arguing against > scaling back to give the newcomers some room to establish themselves. I'm > arguing against the specific way that Reno and CUBIC behave to try to > accomplish that. :-) > =3D=3D> I agree too. But I think one of the key challenges here could be wh= en 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. --0000000000005d0e3005f864c6ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 2, 2023 at 10:03=E2=80=AF= PM Neal Cardwell <ncardwell@goog= le.com> wrote:


On Sun, Apr 2, 2023 at 8:14=E2= =80=AFAM Sebastian Moeller <moeller0@gmx.de> wrote:
Hi Ayush,

> On Mar 28, 2023, at 11:36, Ayush Mishra via Bloat <bloat@lists.bufferbloat.ne= t> wrote:
>
> Hey Neal,
>
> I was revisiting this thread before presenting this paper in iccrg tom= orrow - and I was particularly intrigued by one of the motivations you ment= ioned for BBR:
>
> "BBR is not trying to maintain a higher throughput than CUBIC in = these kinds of scenarios with steady-state bulk flows. BBR is trying to be = robust to the kinds of random packet loss that happen in the real world whe= n there are flows dynamically entering/leaving a bottleneck."

But isn't "when there are flows dynamically entering" actuall= y a bona fide reason for the already established flows to scale back a bit,= to give the new-commers some room to establish themselves?

Yes, I agree that "when there are flows dynamical= ly entering" is actually a bona fide reason for the already establishe= d flows to scale back to give the newcomers some room to establish themselv= es. I'm not arguing against scaling back to give the newcomers some roo= m to establish themselves. I'm arguing against the specific way that Re= no and CUBIC behave to try to accomplish that. :-)
=3D=3D> I agree too. But I think one of the key challenges he= re 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 t= he time the long-running flow backs off, the congestion it was responding t= o has already ended because the tiny flows have exited the bottleneck (thin= k microbursts caused by flows that last 1-2 RTTs). In a perfect world we= 9;d like to deal with elephant=C2=A0and mice flows in isolation at the swit= ch, 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 conges= tion and not just brief microbursts. This is just off the top of my head, s= o I'm not sure how something like this would play out in the overall dy= namics and convergence of the algorithm that implements it.
--0000000000005d0e3005f864c6ed--