From: Neal Cardwell <ncardwell@google.com> To: Dave Taht <dave.taht@gmail.com> Cc: bloat <bloat@lists.bufferbloat.net>, codel@lists.bufferbloat.net, ECN-Sane <ecn-sane@lists.bufferbloat.net>, Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>, flent-users <flent-users@flent.org>, BBR Development <bbr-dev@googlegroups.com>, ghosal@cs.ucdavis.edu, tflynn@ucdavis.edu Subject: [Flent-users] Re: [bbr-dev] D* tcp looks pretty good, on paper Date: Fri, 8 Jan 2021 10:38:05 -0500 [thread overview] Message-ID: <CADVnQynZM-9y+41Vgss4_EC5R6XArOMGD4eYWUVvp_hGY7=SUA@mail.gmail.com> (raw) In-Reply-To: <CAA93jw6qczFKudMt3kzmGzRmCvgoemBta69AoENX3oCtR+CnYw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1592 bytes --] On Thu, Jan 7, 2021 at 1:35 PM Dave Taht <dave.taht@gmail.com> wrote: > See: https://arxiv.org/pdf/2012.14996.pdf Thanks for the link! > > Things I really like: > > * they used flent > * Using "variance" as the principal signal. This is essentially one of > the great unpublished and unanalyzed improvements on the minstrel > algorithm as well > * Conventional ecn response > * outperforms bbr on variable links > What did you have in mind by "variable links" here? (I did not see that term in the paper.) Rather than characterizing the algorithm as using "variance" as the principal signal, my sense is that the estimated BDP is the primary signal, and the algorithm uses variance as a secondary signal to adapt the gain. I would be interested to hear how the algorithm performs in real-world paths with high degrees of aggregation and RTT variance, including wifi, cellular, and 10Gbps+ Ethernet LANs. The paper mentions "TCP D* sets the window to its estimated BDP," and our experience is that setting cwnd to the estimated BDP produces unusably low throughput over these kinds of paths. In these paths the min_rtt is very different from the typical RTT, so setting the cwnd purely using the min_rtt can lead to very significant underutilization: https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00#page=5 Another interesting aspect is that it seems completely agnostic to packet losses. It would be interesting to see how the algorithm behaves in shallow or mid-sized buffers with a highly dynamic mix of traffic. best, neal [-- Attachment #2: Type: text/html, Size: 2504 bytes --]
next prev parent reply other threads:[~2021-01-08 15:38 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-07 18:35 [Flent-users] " Dave Taht 2021-01-07 19:20 ` [Flent-users] " Taran Lynn 2021-01-07 20:25 ` [Flent-users] Re: [Make-wifi-fast] " Bob McMahon 2021-01-07 21:41 ` Dave Taht 2021-01-07 22:22 ` Bob McMahon 2021-01-08 14:35 ` [Flent-users] Re: [Ecn-sane] " Rodney W. Grimes 2021-01-08 17:52 ` Bob McMahon 2021-01-08 15:38 ` Neal Cardwell [this message] 2021-01-08 16:13 ` [Flent-users] Re: [Make-wifi-fast] [bbr-dev] " Jonathan Morton 2021-01-08 16:24 ` Bryson Richard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.flent.org/postorius/lists/flent-users.flent.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CADVnQynZM-9y+41Vgss4_EC5R6XArOMGD4eYWUVvp_hGY7=SUA@mail.gmail.com' \ --to=ncardwell@google.com \ --cc=bbr-dev@googlegroups.com \ --cc=bloat@lists.bufferbloat.net \ --cc=codel@lists.bufferbloat.net \ --cc=dave.taht@gmail.com \ --cc=ecn-sane@lists.bufferbloat.net \ --cc=flent-users@flent.org \ --cc=ghosal@cs.ucdavis.edu \ --cc=make-wifi-fast@lists.bufferbloat.net \ --cc=tflynn@ucdavis.edu \ --subject='[Flent-users] Re: [bbr-dev] D* tcp looks pretty good, on paper' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox