From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 7FEA03B29E for ; Fri, 26 Aug 2022 09:36:46 -0400 (EDT) Received: by mail-qk1-x72d.google.com with SMTP id h27so1087168qkk.9 for ; Fri, 26 Aug 2022 06:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=E7baIF8ccwMo7CVsEWLkbsxpsn7Ty5g3IdjrI1dPApI=; b=awfSDT5Q2OEOgwO7PMET9L38TpfAoUfmHi46YPecO0vmAnuQm0KEJp6eS5acm0seHB 3DhdfEmLAkApl1gSox5ZSU01v6JxjTDv93fyiNgAN8hUWqHKO+fVASrGTRLLnm5dAWkG Sn11lleGImgUJ4RsAWsaqf9H7YqoffnB5vncW28SNDTjZ7+n9Bl+lom6jkcoEEj4/4yk CcJZqfZhY1GdJxhQtDkS0d8m8mOrXOLE3BCbWAQWAgM33XjHJaVagAFTlM49dLA/B0hC eAcTlE6QA4mxVxo22Gh2cyBnC5KswLKLUIMeD7zJDXngb/Ar3DleGUTcyr50EUTD7oZb aidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=E7baIF8ccwMo7CVsEWLkbsxpsn7Ty5g3IdjrI1dPApI=; b=eQAZnV1KYkxA2RcSiz96V/Ofh9cBKBTxoKZdBfl2rPKiidPEcOLimhwfpa5A1chf9N cwrtFWVcNt73HestMjrKYDFBb+zRUVxUiBXbOGP7Fhfe5cZzTi9e2erItGCxhqSJYZWX BgG5QmEjoRzFA4frDty75LZRbRv1NFzMOdMGIXvxhuDTOTmhonT9WJXpzg7ny7ywEsbI MMdwCGsbtDw6bEvVoRSAdKlcUt0QscC1BdOzfgMtVdNpaujHb8ZVEha+am8wU7Khg9q1 140SMT5SpC/UHDJNsMpDaX7yCdj3B4WGwRcXFKiGM8Okk2YPjGRWnumuW7aQo4VnK1TD SDKA== X-Gm-Message-State: ACgBeo3epO4ohYKFGHYamTXGUEny+XBYdtWbdbAWphYlG5BidD6TZOyi lIzX4X2vI3mTfv1El7whK11+fEhnyqwgKlemGS0v9Q== X-Google-Smtp-Source: AA6agR76fiO4737TM3sCB/+xY0zzaaaSovsfck2uMNELnDWmxvDD6CgGTA4AmpH3XhWk+wSs7+L5Qzr8PYG9TxCHDmE= X-Received: by 2002:a05:620a:1a03:b0:6bb:8e3e:8a1a with SMTP id bk3-20020a05620a1a0300b006bb8e3e8a1amr6549642qkb.296.1661521005672; Fri, 26 Aug 2022 06:36:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Fri, 26 Aug 2022 09:36:29 -0400 Message-ID: To: Dave Taht Cc: bloat , BBR Development , ayush@comp.nus.edu.sg Content-Type: multipart/alternative; boundary="0000000000005517f105e7250111" Subject: Re: [Bloat] 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: Fri, 26 Aug 2022 13:36:46 -0000 --0000000000005517f105e7250111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I agree the assumptions are key here. One key aspect of this paper is that it focuses on the steady-state behavior of bulk flows. Once you allow for short flows (like web pages, RPCs, etc) to dynamically enter and leave a bottleneck, the considerations become different. As is well-known, Reno/CUBIC will starve themselves if new flows enter and cause loss too frequently. For CUBIC, for a somewhat typical 30ms broadband path with a flow fair share of 25 Mbit/sec, if new flows enter and cause loss more frequently than roughly every 2 seconds then CUBIC will not be able to utilize its fair share. For a high-speed WAN path, with 100ms RTT and fair share of 10 Gbit/sec, if new flows enter and cause loss more frequently than roughly every 40 seconds then CUBIC will not be able to utilize its fair share. Basically, loss-based CC can starve itself in some very typical kinds of dynamic scenarios that happen in the real world. 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 when there are flows dynamically entering/leaving a bottleneck. cheers, neal On Thu, Aug 25, 2022 at 8:01 PM Dave Taht via Bloat < bloat@lists.bufferbloat.net> wrote: > I rather enjoyed this one. I can't help but wonder what would happen > if we plugged some different assumptions into their model. > > https://www.comp.nus.edu.sg/~bleong/publications/imc2022-nash.pdf > > -- > FQ World Domination pending: > https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --0000000000005517f105e7250111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I agree the assumptions are key here. One key aspect = of this paper is that it focuses on the steady-state behavior of bulk flows= .

Once you allow for short flows (like web pages, RPCs, = etc) to dynamically enter and leave a bottleneck, the considerations become= different. As is well-known, Reno/CUBIC will starve themselves if new flow= s enter and cause loss too frequently. For CUBIC, for a somewhat typical 30= ms broadband path with a flow fair share of 25 Mbit/sec, if new flows enter= and cause loss more frequently than roughly every 2 seconds then CUBIC wil= l not be able to utilize its fair share. For a high-speed WAN path, with 10= 0ms RTT and fair share of 10 Gbit/sec,=C2=A0 if new flows enter and cause l= oss more frequently than roughly every 40 seconds then CUBIC will not be ab= le to utilize its fair share. Basically, loss-based CC can starve itself in= some very=C2=A0typical=C2=A0kinds of dynamic scenarios that happen in the = real world.

BBR is not trying to maintain a higher= throughput than CUBIC in these kinds of scenarios with steady-state bulk f= lows. BBR is trying to be robust to the kinds of random packet loss that ha= ppen in the real world when there are flows dynamically entering/leaving a = bottleneck.

cheers,
neal

<= /div>



On Thu, Aug 25, 2022 at 8:01 PM Dave Tah= t via Bloat <bloat@lists.= bufferbloat.net> wrote:
I rather enjoyed this one. I can't help but wonder what = would happen
if we plugged some different assumptions into their model.

https://www.comp.nus.edu.sg/~bleong= /publications/imc2022-nash.pdf

--
FQ World Domination pending: https://blog.cerowrt.or= g/post/state_of_fq_codel/
Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--0000000000005517f105e7250111--