From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4CC7B3B29E for ; Mon, 29 Aug 2022 18:17:03 -0400 (EDT) Received: by mail-ej1-x62b.google.com with SMTP id se27so10781963ejb.8 for ; Mon, 29 Aug 2022 15:17:03 -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=DAGIFiBZcvwHffcUNE/eKBh/H6WR1/SwNtCm4JIrQpo=; b=MxKr0xYXe+FIJ++Om3uVgFoECU0ApnmYIL5sSLO8ATBlrLFk8FeKmWoixqeRLY/viU o7IDQDYl+WSnRFHvWR2hFzv6UE5opxJjCoJEFrpGmfeR0kFXgix/SUgAPj1xroxB4mXi pijwYSRsXb7HXI2419l/sahG+MElU7hkynkQQ= 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=DAGIFiBZcvwHffcUNE/eKBh/H6WR1/SwNtCm4JIrQpo=; b=L2K1equurziWToyvXiF5YbXHneb1kZg/dlabZVtLJKtIXp0RsdHfVwRwvKjeHULAzH ms9eLNdSkXeUMxILVKrH0ZH9UczTODIztfMtycnAm5eZEUDVpx7tKIwnKW0Hb8ToYRd+ 9nd84qiSq2ydrAG7Sfby4ES+ZPYTqaz4FDCHStu5VeZA67TCnl+do9+MhxUhnQ+PyPO1 68ZtXdiqQz2BEAWF4FeuUSjxFCkcZ65K1zwmFrfGS0HwpvyQVcoxc5PtdnwzaAT9bZIp djCI/w5Okot2q/3wvHA01UAL5OD+K90XBNjuqejEafpg0kQsgHuH/cgEs/XWJi/L+r3H 9R0Q== X-Gm-Message-State: ACgBeo2pWmowRFrkZkjSlAN692XToTzrxzau49NS2SfM5vFu6qamULH7 GYhHK61h1aQr7MTw91WSVxTY0eznk4P+IFLpgqZTPUWyGlChZrPuoO9yi9N79Z8aegzXvSfD42l po5FGPSNQW5mWw3vM358FXRA/kkCIlg== X-Google-Smtp-Source: AA6agR7q8lo+kIAVi2lFdcsYRpss9cn0sinrsZHgmO0Z4yWMU+KYJr9n0NR3HTN8Sr/sVzj/UAGhdNH34OkVIXpJjY0= X-Received: by 2002:a17:907:94c6:b0:730:b3a6:d612 with SMTP id dn6-20020a17090794c600b00730b3a6d612mr15929712ejc.28.1661811421764; Mon, 29 Aug 2022 15:17:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bob McMahon Date: Mon, 29 Aug 2022 15:16:50 -0700 Message-ID: To: Neal Cardwell Cc: Dave Taht , bloat , BBR Development , ayush@comp.nus.edu.sg Content-Type: multipart/alternative; boundary="0000000000007af01705e7689f4a" 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, 29 Aug 2022 22:17:03 -0000 --0000000000007af01705e7689f4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure thing. Defining some multivariate signals using "non-bulk flow" or "realistic" traffic scenarios that could be automated (and a proxy for user QoE) would be very useful for L2 driver, MAC/PHY, and AP scheduling engineers allowing them to provide the best quality packet forwarding plane products possible for the transport layers and those engineering teams. Bob On Mon, Aug 29, 2022, 1:07 PM Neal Cardwell wrote: > Thanks for the pointers, Bob. > > best regards, > neal > > > On Mon, Aug 29, 2022 at 12:47 PM 'Bob McMahon' via BBR Development < > bbr-dev@googlegroups.com> wrote: > >> Thanks Neal. You might want to check out the flows released as iperf 2. >> Basically >> instantiate flows and run them. There typically is a controller running >> python3 (v 3.10 or better) that uses ssh pipes to DUTs. The design is ev= ent >> driven and >> utilizes python's asyncio >> which is quite >> powerful. The DUTs just need iperf2 and ssh. >> >> The code is at an alpha level and we're looking for broader industry >> support and contributions. Both in realtime plotting but also in things >> like multivariate regression detection using statistical process control= s >> (SPC) e.g. Hoteling >> . >> There is some crude clustering code around latency too which uses >> Kolmogorov-Smirnov >> distance >> matrices per the histograms. >> >> A suggestion is that those in developer and control test roles >> synchronize their device clocks with PTP. Iperf 2 supports one way delay >> (OWD) calculations but these only work if the clocks are sync'd. These = in >> turn can be used per Little's law >> to calculate effective >> average queue depth, though this typically assumes a steady state >> measurement. >> >> Bob >> >> On Sun, Aug 28, 2022 at 4:54 PM Neal Cardwell >> wrote: >> >>> If you are talking about the screenshot of the UI at >>> https://github.com/google/transperf, yes, that particular test is a >>> simple bulk flow test to show a simple case to give a sense of what the= UI >>> looks like. :-) >>> >>> We use a few different approaches that can examine dynamic flows causin= g >>> packet loss: >>> >>> (1) The test configuration language is Python, so you can construct >>> arbitrarily fancy dynamic flow scenarios with arbitrary numbers of flow= s >>> starting and stopping at arbitrary times. >>> >>> (2) The tests can also use netperf command line options to run periodic >>> short transfers. (And we welcome patches to integrate support for other >>> tools.) >>> >>> (3) We also run a fair number of tests for robustness to loss just usin= g >>> randomly injected packet loss (using netem). >>> >>> These are just some of the approaches we have used, and I don't claim >>> that these are the only or best approaches to look at this. :-) >>> >>> cheers, >>> neal >>> >>> >>> On Sun, Aug 28, 2022 at 6:39 PM Bob McMahon >>> wrote: >>> >>>> Hi Neal, >>>> >>>> These look like steady-state bulk flow tests unless I'm missing >>>> something. >>>> >>>> Bob >>>> >>>> On Sun, Aug 28, 2022 at 11:43 AM Neal Cardwell >>>> wrote: >>>> >>>>> Sure. For testing these kinds of properties of the BBR algorithm we >>>>> use various transperf test cases. The transperf tool is something Soh= eil >>>>> Hassas Yeganeh and our team cooked up and open-sourced here: >>>>> >>>>> https://github.com/google/transperf >>>>> >>>>> Best regards, >>>>> neal >>>>> >>>>> On Sat, Aug 27, 2022, 4:43 PM Bob McMahon >>>>> wrote: >>>>> >>>>>> 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 < >>>>>>> bob.mcmahon@broadcom.com> 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 iperf 2 with things >>>>>>>> like --bounceback and --burst-period and --burst-period >>>>>>>> . We could pull >>>>>>>> the size and period from a known distribution or distributions tho= ugh not >>>>>>>> sure what to pick. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bob >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>>> On Fri, Aug 26, 2022 at 6:36 AM 'Neal Cardwell' via BBR Developmen= t >>>>>>>> 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 flo= ws. >>>>>>>>> >>>>>>>>> Once you allow for short flows (like web pages, RPCs, etc) to >>>>>>>>> dynamically enter and leave a bottleneck, the considerations beco= me >>>>>>>>> different. As is well-known, Reno/CUBIC will starve themselves if= new flows >>>>>>>>> enter and cause loss too frequently. For CUBIC, for a somewhat ty= pical 30ms >>>>>>>>> broadband path with a flow fair share of 25 Mbit/sec, if new flow= s 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 it= self in >>>>>>>>> some very typical kinds of dynamic scenarios that happen in the r= eal world. >>>>>>>>> >>>>>>>>> BBR is not trying to maintain a higher throughput than CUBIC in >>>>>>>>> these kinds of scenarios with steady-state bulk flows. BBR is try= ing 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.pd= f >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 Googl= e >>>>>>>>> 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 i= ntended >>>>>>>> solely for the use of the individual or entity to whom it is addre= ssed and >>>>>>>> may contain information that is confidential, legally privileged, = protected >>>>>>>> by privacy laws, or otherwise restricted from disclosure to anyone= else. If >>>>>>>> you are not the intended recipient or the person responsible for d= elivering >>>>>>>> the e-mail to the intended recipient, you are hereby notified that= any use, >>>>>>>> copying, distributing, dissemination, forwarding, printing, or cop= ying 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 comput= er, and >>>>>>>> destroy any printed copy of it. >>>>>>> >>>>>>> >>>>>> This electronic communication and the information and any files >>>>>> transmitted with it, or attached to it, are confidential and are int= ended >>>>>> solely for the use of the individual or entity to whom it is address= ed and >>>>>> may contain information that is confidential, legally privileged, pr= otected >>>>>> by privacy laws, or otherwise restricted from disclosure to anyone e= lse. If >>>>>> you are not the intended recipient or the person responsible for del= ivering >>>>>> the e-mail to the intended recipient, you are hereby notified that a= ny use, >>>>>> copying, distributing, dissemination, forwarding, printing, or copyi= ng of >>>>>> this e-mail is strictly prohibited. If you received this e-mail in e= rror, >>>>>> please return the e-mail to the sender, delete it from your computer= , and >>>>>> destroy any printed copy of it. >>>>> >>>>> >>>> This electronic communication and the information and any files >>>> transmitted with it, or attached to it, are confidential and are inten= ded >>>> solely for the use of the individual or entity to whom it is addressed= and >>>> may contain information that is confidential, legally privileged, prot= ected >>>> by privacy laws, or otherwise restricted from disclosure to anyone els= e. If >>>> you are not the intended recipient or the person responsible for deliv= ering >>>> the e-mail to the intended recipient, you are hereby notified that any= use, >>>> copying, distributing, dissemination, forwarding, printing, or copying= of >>>> this e-mail is strictly prohibited. If you received this e-mail in err= or, >>>> please return the e-mail to the sender, delete it from your computer, = and >>>> destroy any printed copy of it. >>> >>> >> 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. >> >> -- >> 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/CAHb6Lvqi9%3Dr0H6uNekoCs8tm450= Bd-6%2BA9v7XMszX73h7yVMPg%40mail.gmail.com >> >> . >> > --=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. --0000000000007af01705e7689f4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure thing. Defining some multivariate s= ignals using "non-bulk flow" or "realistic" traffic sce= narios that could=C2=A0be automated (and a proxy for user=C2=A0QoE) would b= e very useful for L2 driver, MAC/PHY, and AP scheduling engineers allowing = them to provide=C2=A0the=C2=A0best quality packet forwarding plane products= possible for the transport layers and those engineering teams.

Bob= =C2=A0

On Mon, Aug 29, 2022, 1:07 PM Neal Cardwell <ncardwell@google.com> wro= te:
Thanks for the pointers,=C2=A0 Bob.

best= regards,
neal


On Mon, Aug 29, 2022 at 12:47 = PM 'Bob McMahon' via BBR Development <bbr-dev@googlegroups= .com> wrote:
Thanks Neal. You might want to check out the flows released as iperf 2. Basically instant= iate flows and run them. There typically is a controller running python3 (v= 3.10 or better) that uses ssh pipes to DUTs. The design is event driven and utilizes python's asyncio which is quite powerful. The DUTs just need iperf2 and ssh.<= br>
The code is at an alpha level and we're looking for broader indu= stry support and contributions. Both in realtime=C2=A0plotting but also in = things like multivariate regression detection using statistical=C2=A0proces= s controls (SPC) e.g. Hoteling. = There is some crude clustering code around latency too which uses Kolmogorov-Smirnov=C2=A0distance matrices = per the histograms.

A suggestion is that those in developer and cont= rol test roles synchronize their device clocks with PTP. Iperf 2 supports o= ne way delay (OWD) calculations but these only work if the clocks are sync&= #39;d.=C2=A0 These in turn can be used per=C2=A0Little&#= 39;s law to calculate effective average queue depth, though this typica= lly assumes a steady state measurement.

Bob=C2=A0

On Sun, Aug 28, 202= 2 at 4:54 PM Neal Cardwell <ncardwell@google.com> wrote:
If y= ou are talking about the screenshot of the UI at=C2=A0=C2=A0https://github.com/google/transperf,=C2=A0yes, that particular te= st is a simple bulk flow test to show a simple case to give a sense of what= the UI looks like. :-)

We use a few different approache= s that can examine dynamic flows causing packet loss:=C2=A0

(1) The test configuration language is Python, so you can construct= arbitrarily fancy dynamic flow scenarios with arbitrary numbers of flows s= tarting and stopping at arbitrary times.

(2) The t= ests can also use netperf command line options to run periodic short transf= ers. (And we welcome patches to integrate support for other tools.)

(3) We also run a fair number of tests for robustness to = loss just using randomly injected packet loss (using netem).

=
These are just some of the approaches we have used, and I don= 9;t claim that these are the only or best approaches to look at this. :-)

cheers,
neal


On= Sun, Aug 28, 2022 at 6:39 PM Bob McMahon <bob.mcmahon@broadcom.co= m> wrote:
Hi Neal,

These look like steady-state = bulk flow tests unless I'm missing something.

Bob
On Sun, A= ug 28, 2022 at 11:43 AM Neal Cardwell <ncardwell@google.com> wr= ote:
Sure. For testing these kinds of properties of the= BBR algorithm we use various transperf test cases. The transperf tool is s= omething Soheil Hassas Yeganeh and our team cooked up and open-sourced here= :

=

Best regards,
neal

On Sat, Aug 27, 2022, 4:= 43 PM Bob McMahon <bob.mcmahon@broadcom.com> wro= te:
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 <ncardwell@google.com> wrote:
Hi Bob,

<= /div>
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 <bob.mcmahon@broadcom.com> wrote:
Hi Neal,

Any th= oughts on tooling 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 like --bounceback and --burst-period and --burst-pe= riod. We could pull the size and period from a known distribution or di= stributions though not sure what to pick.

Thanks,
Bob

Bob<= /div>
O= n Fri, Aug 26, 2022 at 6:36 AM 'Neal Cardwell' via BBR Development = <bbr-dev@googlegroups.com> wrote:
=
Ye= s, I agree the assumptions are key here. One key aspect of this paper is th= at 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 w= ell-known, Reno/CUBIC will starve themselves if new flows enter and cause l= oss too frequently. For CUBIC, for a somewhat typical 30ms broadband path w= ith a flow fair share of 25 Mbit/sec, if new flows enter and cause loss mor= e frequently than roughly every 2 seconds then CUBIC will not be able to ut= ilize its fair share. For a high-speed WAN path, with 100ms RTT and fair sh= are 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 utilize its f= air share. Basically, loss-based CC can starve itself in some very=C2=A0typ= ical=C2=A0kinds of dynamic scenarios that happen in the real world.

BBR is not trying to maintain a higher throughput than CU= BIC 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 wo= rld 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:
<= /div>
I rather enjoyed thi= s one. I can't help but wonder what would happen
if we plugged some different assumptions into their model.

ht= tps://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.bufferblo= at.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@googleg= roups.com.
To view this discussion on the web visit https://groups.google.com/d/msgi= d/bbr-dev/CADVnQykKbnxpNcpuZATug_4VLhV1%3DaoTTQE2263o8HF9ye_TQg%40mail.gmai= l.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.

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.

--
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/CAHb6Lvqi9= %3Dr0H6uNekoCs8tm450Bd-6%2BA9v7XMszX73h7yVMPg%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. --0000000000007af01705e7689f4a--