From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 A00B43B29D for ; Sat, 27 Aug 2022 10:44:44 -0400 (EDT) Received: by mail-qv1-xf34.google.com with SMTP id q8so3213201qvr.9 for ; Sat, 27 Aug 2022 07:44:44 -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=MwUXuwK36G07AaIrd76tv7rWip/8lLzdJF5Lp3jOhSE=; b=LRVgYL5PLKMGpybaQ1YuAhAlscvv8BXJCC07VAByKOnGz3xu/LKrKI0QOnkc00CNRn QzeJosU5lWc4XGf/PqZBqCkw6BmxVKsBaiPvzy4oqnVd9l0XLIbOwH0sllhYVSRliEse 1rd6X/oC2kG6FiE3Z9nmvCHNxEbjktggg70FySGgdP8WS9U5eSgihcfsb6DyJHYY8Edu zQPMw+ebVTd1ufoPIvQddB2/yNrtHWx9GtNkf14V6W37D3tZndAsDgJm85xGo50WALQ1 Oj4XWONgZoQaHIg0MWf/J7UO2ZENby6RWrPw+BPRMih5wsOi1IJ/FrhRa79zNmfi4mlT +X9g== 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=MwUXuwK36G07AaIrd76tv7rWip/8lLzdJF5Lp3jOhSE=; b=QQbBSQkeDVj+l1uCOhc43AEkOPXdnz3euQXc19fcfael5L6ms15OsUYMOPZlXmorvS zyeOM+QOlITJtb6qcluVZo9CzOz5/zNe5SQhrThDYljxp0EANLWjvPdybFQ4BGHT0FuT oSVvBlXlgpvePR4o8C6/jiKgxuOeOrDRRAOO52iGevKFN0HbWnhMul3+qgpdl4R/m+TY cHmyUQGk78Z0PLkc8K98aopUgTFh1QrET6BgP3CIMpqBIsozsaum3XO5f4SsFrzCPrec ZizkYwWV+QwCPP6qzJAL7JWjx33o9GL/fqHzP+JvEWCif65/OdX298vuQWOoxGnhQaVy zBIQ== X-Gm-Message-State: ACgBeo0wiQLlbwi/O6qvWy1MwUPtQRUsjX+e20eLm5tIc2sEoP16hosu cM/x8uyVK8qPaPG7Ig519IHZXySt8CbfX1P8nLFskA== X-Google-Smtp-Source: AA6agR7A1ymdfb51uXbW83Rg4KYOwtjscKejEefATKzgK0OVY9cMt0qSV7ARrcghb57boJ2egsOvo5yRJRAC8PKD0ak= X-Received: by 2002:a05:6214:1c47:b0:474:8d1e:f432 with SMTP id if7-20020a0562141c4700b004748d1ef432mr3768323qvb.94.1661611483976; Sat, 27 Aug 2022 07:44:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Sat, 27 Aug 2022 10:44:27 -0400 Message-ID: To: Bob McMahon Cc: Dave Taht , bloat , BBR Development , ayush@comp.nus.edu.sg Content-Type: multipart/alternative; boundary="00000000000042293d05e73a120b" 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 14:44:44 -0000 --00000000000042293d05e73a120b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ipe= rf > 2 with things like --bouncebac= k > and --burst-period and --burst-period > . We could pull the > size and period from a known distribution or distributions though not sur= e > 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 dynamicall= y >> enter and leave a bottleneck, the considerations become different. As is >> well-known, Reno/CUBIC will starve themselves if new flows enter and cau= se >> loss too frequently. For CUBIC, for a somewhat typical 30ms broadband pa= th >> 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 fa= ir >> 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 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. >> >> 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 Group= s >> "BBR Development" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> 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 intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > 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, and > destroy any printed copy of it. --00000000000042293d05e73a120b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,

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


On Fri, Aug 26, 2022 at 4:54 PM= Bob McMahon <bob.mcmahon@br= oadcom.com> wrote:
Hi Neal,

Any thoughts on tooling to gene= rate and measure the traffic flows BBR is designed to optimize? I've be= en adding some low duty cycle support in iperf 2 with things like --b= ounceback 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 &= #39;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.

<= div>Once you allow for short flows (like web pages, RPCs, etc) to dynamical= ly 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 m= ore 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 frequent= ly 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=C2=A0t= ypical=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 flows. BBR is tryi= ng 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 <<= a href=3D"mailto:bloat@lists.bufferbloat.net" target=3D"_blank">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

--
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.
--00000000000042293d05e73a120b--