From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 417583B29D for ; Sat, 27 Aug 2022 16:43:16 -0400 (EDT) Received: by mail-ej1-x62f.google.com with SMTP id se27so1154297ejb.8 for ; Sat, 27 Aug 2022 13:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=ZcsJLQSJh+P1c73sXRMkTYFJDvsteHU6QZxBFzvVTNc=; b=CkI/CezaoV8vIgm49U7wJeR8bf0W1ZYK6ZOk10j8ec1pax8Fc5C0zY3ftd6eQ05n1G xG0ncDGywZxsH+XpiXfa2n9Z1vfY3mfoIhzc/4cKPMbt8yihDFiUtiqOK5N1oJp4VIOl +N/wYMJe1Nbt3hB6116igidNB0PrpYBysQkt8= 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=ZcsJLQSJh+P1c73sXRMkTYFJDvsteHU6QZxBFzvVTNc=; b=4/bUyT8xfDMoyoLqUihMUgc4OnNLLkUHGjvS1sNU2xc9uHO4Msu9s0eoSGVY+g8q1/ zJ6IRehkb15muTgjTGNWgyYH35bCggPG4y4zwSElGkNIosonY1IJsYuJMgJJ7uOECfb4 AUnC2/qJK7XmmFFFJndDldT9x1F37cOxPNZYReDlMGJsgagWnBATNAbxk9paKo7EMMiw oaif4F5I7rFq+BbuRgfUH1+gT0GT7PVCVyt28lhEMRCgcsbQgBRNCP3ojdOjddnf0nSw 75oAD1uqiU0O9I0kKRC1SFQXwc6ZXHmt+6zbfkqXHnNpl0D3+/lj/L/CduNN9Bj7LCOY HzGw== X-Gm-Message-State: ACgBeo1KvR17DqAu88SYn9jGEf2n0F6AbF2ICYqRyH3xLA03fbhen1XT nZDh0YcIk88DHZaFaBQA7a66FJvsbuWiEKeu3NXtm+DdPt/eqgkrhmnQ5VnzQqksP5ESpKVQpeJ Y0zhcHLSPcaRtRvrC1GwU5HOtK20h6A== X-Google-Smtp-Source: AA6agR6s3V5cA0/2gjziUiQhhioktwJ4wBgXQSP5xNoywl+nSJPaMxn/DPjKqw3+P5Lw7dln1rvgSLXEyuf+TKoERUc= X-Received: by 2002:a17:906:5387:b0:73d:af6c:6830 with SMTP id g7-20020a170906538700b0073daf6c6830mr9233339ejo.400.1661632994960; Sat, 27 Aug 2022 13:43:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bob McMahon Date: Sat, 27 Aug 2022 13:43:03 -0700 Message-ID: To: Neal Cardwell Cc: Dave Taht , bloat , BBR Development , ayush@comp.nus.edu.sg Content-Type: multipart/alternative; boundary="0000000000006998ee05e73f146a" 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: Sat, 27 Aug 2022 20:43:16 -0000 --0000000000006998ee05e73f146a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Curious to what you're doing during development, if you can share? Thanks, Bob On Sat, Aug 27, 2022 at 7:44 AM Neal Cardwell wrote: > Hi Bob, > > Good question. I can imagine a number of different techniques to generate > and measure the traffic flows for this kind of study, and don't have any > particular suggestions. > > neal > > > On Fri, Aug 26, 2022 at 4:54 PM Bob McMahon > wrote: > >> Hi Neal, >> >> Any thoughts on tooling to generate and measure the traffic flows BBR is >> designed to optimize? I've been adding some low duty cycle support in ip= erf >> 2 with things like --bounceba= ck >> and --burst-period and --burst-period >> . We could pull the >> size and period from a known distribution or distributions though not su= re >> what to pick. >> >> Thanks, >> Bob >> >> Bob >> >> On Fri, Aug 26, 2022 at 6:36 AM 'Neal Cardwell' via BBR Development < >> bbr-dev@googlegroups.com> wrote: >> >>> 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 f= lows >>> 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 ente= r >>> 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 ab= le >>> to utilize its fair share. Basically, loss-based CC can starve itself i= n >>> some very typical kinds of dynamic scenarios that happen in the real wo= rld. >>> >>> 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 ro= bust >>> to the kinds of random packet loss that happen in the real world when t= here >>> 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 >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "BBR Development" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bbr-dev+unsubscribe@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/bbr-dev/CADVnQykKbnxpNcpuZATug_4VLhV1= %3DaoTTQE2263o8HF9ye_TQg%40mail.gmail.com >>> >>> . >>> >> >> This electronic communication and the information and any files >> transmitted with it, or attached to it, are confidential and are intende= d >> solely for the use of the individual or entity to whom it is addressed a= nd >> may contain information that is confidential, legally privileged, protec= ted >> by privacy laws, or otherwise restricted from disclosure to anyone else.= If >> you are not the intended recipient or the person responsible for deliver= ing >> the e-mail to the intended recipient, you are hereby notified that any u= se, >> copying, distributing, dissemination, forwarding, printing, or copying o= f >> this e-mail is strictly prohibited. If you received this e-mail in error= , >> please return the e-mail to the sender, delete it from your computer, an= d >> destroy any printed copy of it. > > --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --0000000000006998ee05e73f146a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Curious to what you're doing during development, if yo= u can share?

Thanks,
Bob

On Sat, Aug 27, 2022 at 7:44 AM Neal Card= well <ncardwell@google.com&g= t; wrote:
Hi Bob,

Good question. I can imagine a number= of different techniques to generate and measure the traffic flows for this= kind of study, and don't have any particular suggestions.
neal


=
On Fri, Aug 26, 2022 at 4:54 PM Bob M= cMahon <bo= b.mcmahon@broadcom.com> wrote:
Hi Neal,

Any thoughts on tool= ing to generate and measure the traffic flows BBR is designed to optimize? = I've been adding some low duty cycle support in iperf 2 with things lik= e --bounceback and --burst-period and --burst-period. We could pull= the size and period from a known distribution or distributions though not = sure what to pick.

Thanks,
Bob

Bob

On Fri, Aug 26, 2022 at = 6:36 AM 'Neal Cardwell' via BBR Development <bbr-dev@googlegroups.com>= wrote:
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 differe= nt. 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 broad= band path with a flow fair share of 25 Mbit/sec, if new flows enter and cau= se 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,=C2=A0 if new flows enter and cause loss more= frequently than roughly every 40 seconds then CUBIC will not be able to ut= ilize its fair share. Basically, loss-based CC can starve itself in some ve= ry=C2=A0typical=C2=A0kinds of dynamic scenarios that happen in the real wor= ld.

BBR is not trying to maintain a higher through= put than CUBIC in these kinds of scenarios with steady-state bulk flows. BB= R 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 bottlene= ck.

cheers,
neal




On Thu, Aug 25, 2022 at 8:01 PM Dave Taht via Bl= oat <bl= oat@lists.bufferbloat.net> wrote:
I rather enjoyed this one. I can't help but wo= nder 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

--
You received this message because you are subscribed to the Google Groups &= quot;BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bbr-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CADVnQykKbnxpNcpuZATug_4VLhV1%3= DaoTTQE2263o8HF9ye_TQg%40mail.gmail.com.

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it.

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --0000000000006998ee05e73f146a--