From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 059C23B25E for ; Wed, 21 Sep 2016 06:10:51 -0400 (EDT) Received: by mail-wm0-x22a.google.com with SMTP id b130so82555597wmc.0 for ; Wed, 21 Sep 2016 03:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=TGtPv7GQcbuNIY5RYxkmzqpXdQDQ4U8mvB/mFH4yYj0=; b=KH3AuoSCuu7AnpSVAZJpa6gT1WyLbH1XtIhnXEdT0xa0ExDzfJZDmKDl89VWQ40PhN CFVhUwsQAEKIpTvxNjhYeAFxA60RCD4eU5wyxNcbz+J4eZjNZ5JYI/IXFTqSJKLw7GR2 fAI78uKCWNJ7KE3DydN8Q+GHY0ZshTQI7SbfWyX/NSLVdXnrkGvQ8qfrYesdYNwqRAqI ZLGak151ri9uBxiggndTJtsgjTEJAgmhB6FL7vPoMA2yaBkBL67MS/K5xqRmev3oGTBa tVYegwiUWzr6bvjH6xG0/KixSbcS/D9RFGSLm/xXZQf4CyfJ9nVDrpFZoHwKCwyqA6Mi xy/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=TGtPv7GQcbuNIY5RYxkmzqpXdQDQ4U8mvB/mFH4yYj0=; b=krzrQD/MRHFOHvO+yupM1Cw+GlybcPTbhvmrGbiNsuhVCLTpthWBPf4oGiUwKz0h+b xmBVd4rnvv/GYXCAeTDWc+/maZtzX/CLqaBDFyeqTNYkkv1LvbZEfs+XiC7+Bardmran fhsEC8XdFfJ/VwlM4GW/UDy0ULoJdr2YzDGnSlg3QEVmO1R5uDPOTTExWufNR19B+slx LJqHCRJ6NSkAG8EaIqZne9pu1EbMrboWz5Ilj+ZHx4EwsORK2+dQegotZnAEQxIzkrSB E0S0j5XTPbRB3w5ppR8vc5dKsQAgcemLeOXdmhyhr/iTNc4+ck9DvuL45ZO7X/fkyOZn 2AeQ== X-Gm-Message-State: AE9vXwNPupW+4bLR1bSHRp9jiQNz+ntZ5nEXKBG8ApTg/IahVefxLJrmmVaeXtVMpNlPrA== X-Received: by 10.28.65.84 with SMTP id o81mr2621756wma.83.1474452649381; Wed, 21 Sep 2016 03:10:49 -0700 (PDT) Received: from localhost.localdomain (host-89-243-172-136.as13285.net. [89.243.172.136]) by smtp.googlemail.com with ESMTPSA id u64sm31779744wmd.20.2016.09.21.03.10.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Sep 2016 03:10:48 -0700 (PDT) To: Dave Taht References: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> Cc: "cerowrt-devel@lists.bufferbloat.net" From: Alan Jenkins Message-ID: Date: Wed, 21 Sep 2016 11:10:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3AAC48C32E6D58F84B610A3D" Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 10:10:51 -0000 This is a multi-part message in MIME format. --------------3AAC48C32E6D58F84B610A3D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 21/09/16 10:39, Dave Taht wrote: > On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins > wrote: >> are we sure - that's a fairly different algorithm and different expansion of >> the acronym... > Yes it is very different, My cryptic conclusion was a common group of names were involved in both projects (including "Neal" as well). If there wasn't _some_ connection, I think they'd have suggested changing the project name to avoid confusion. > but it appears to have had the germ of at > least one of the good ideas in the soon to be published BBR. > > "BBR detects bufferbloat by comparing its calculated correlation to a > configurable threshold (e.g., 90%) and declaring bufferbloat whenever > the value exceeds the threshold." > > "Upon detecting bufferbloat, BBR immediately sets the TCP cwnd to the > window estimate, rather than gradually reducing the sending rate as > in, for example, Proportional Rate Reduction [19]. Immediately > changing the cwnd has two advantages. 27 First, it stops packet > transmissions immediately and prevents further exacerbating the delay. > When the transmissions resume with the reduced cwnd, they should > experience shorter queuing delay. > > *Second, drastic changes in sending rate should result in sharp > differences in observed RTT, increasing the signal-to-noise ratio in > the observations and improving the correlation calculation*." > > I dunno, I'm just reading tea leaves here! I guess you're referring to PROBE_RTT. PROBE_RTT seems so obvious though, but I guess that's true of all the best ideas :). I thought I saw a few other technical links. The rate measurement is a similar idea. > can't wait for the paper! excite! Aside: just reading the code I think PROBE_RTT will synchronize with other BBR instances sharing the same bottleneck. Very cool if it works that way. (And after PROBE_RTT it randomizes the next PROBE_BW phase, to avoid the harmful kind of synchronization). > >>> video streaming experiments ran on a live, production CDN, where >>> clients included real mobile and desktop users >>> large, multinational production network >> hmm, I suppose... >> >>> ## Acknowledgments ## >>> >>> Van >>> ... >>> Eric >>> ... >> >> ok, there's clearly some overlap here :-D. --------------3AAC48C32E6D58F84B610A3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 21/09/16 10:39, Dave Taht wrote:
On Wed, Sep 21, 2016 at 2:06 AM, Alan Jenkins
<alan.christopher.jenkins@gmail.com> wrote:

are we sure - that's a fairly different algorithm and different expansion of
the acronym...

Yes it is very different,

My cryptic conclusion was a common group of names were involved in both projects (including "Neal" as well).  If there wasn't _some_ connection, I think they'd have suggested changing the project name to avoid confusion.

 but it appears to have had the germ of at
least one of the good ideas in the soon to be published BBR.

"BBR detects bufferbloat by comparing its calculated correlation to a
configurable threshold (e.g., 90%) and declaring bufferbloat whenever
the value exceeds the threshold."

"Upon detecting bufferbloat, BBR immediately sets the TCP cwnd to the
window estimate, rather than gradually reducing the sending rate as
in, for example, Proportional Rate Reduction [19]. Immediately
changing the cwnd has two advantages. 27 First, it stops packet
transmissions immediately and prevents further exacerbating the delay.
When the transmissions resume with the reduced cwnd, they should
experience shorter queuing delay.

*Second, drastic changes in sending rate should result in sharp
differences in observed RTT, increasing the signal-to-noise ratio in
the observations and improving the correlation calculation*."

I dunno, I'm just reading tea leaves here!

I guess you're referring to PROBE_RTT.  PROBE_RTT seems so obvious though, but I guess that's true of all the best ideas :).

I thought I saw a few other technical links.  The rate measurement is a similar idea.

can't wait for the paper!

excite!

Aside: just reading the code I think PROBE_RTT will synchronize with other BBR instances sharing the same bottleneck.  Very cool if it works that way.

(And after PROBE_RTT it randomizes the next PROBE_BW phase, to avoid the harmful kind of synchronization).



video  streaming  experiments  ran  on  a  live,  production  CDN, where
clients included real mobile and desktop users


        

          
large, multinational production network


        

        
hmm, I suppose...



        

          
## Acknowledgments ##

Van
...
Eric
...


        

        

ok, there's clearly some overlap here :-D.


      

    

    

    

  


--------------3AAC48C32E6D58F84B610A3D--