General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Rich Brown <richb.hanover@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>
Subject: [Bloat] BBR talk from Stony Brook University
Date: Sat, 12 Dec 2020 13:11:54 -0500	[thread overview]
Message-ID: <5FAACDE1-CD71-4740-B56E-AAF426480827@gmail.com> (raw)

Google Alerts for "bufferbloat" pointed to this talk at Stony Brook University in New York State:

Dates:  Thursday, December 17, 2020 - 12:30pm to 2:00pm (US EST: UTC-5)
Location:  Zoom - contact events@cs.stonybrook.edu for Zoom info.

Abstract: BBR is a new congestion control algorithm and is seeing increased adoption especially for video traffic. BBR solves the bufferbloat problem in legacy loss-based congestion control algorithms where application performance drops considerably when router buffers are deep. BBR regulates traffic such that router queues don’t build up to avoid the bufferbloat problem while still maintaining high throughput. Though BBR is able to combat bufferbloat for sustained steady traffic such as large file downloads, our analysis shows that video applications experience significantly poor performance when using BBR under deep buffers. In fact, we find that video traffic sees inflated latencies because of long queues at the router, ultimately degrading video performance.

In this talk, I will present our work on the interaction between BBR and streaming video. We investigate the relationship between network metrics such as delay and delivery rate during the video run and the quality of subsequent video segments. However, we find only weak correlations, suggesting that another factor is at play. Our empirical investigation reveals that BBR under deep buffers and high network burstiness severely overestimates available bandwidth and is slower to converge to steady state, both of which result in BBR sending substantially more data into the network, causing a queue buildup. This elevated packet sending rate under BBR is ultimately caused by the router’s ability to absorb bursts in traffic, which destabilizes BBR’s bandwidth estimation and overrides BBR’s expected logic for exiting the startup phase.

Original Notice: https://www.cs.stonybrook.edu/Rebecca-Drucker-Research-Proficiency-Presentation-Investigating-BBR-Bufferbloat-Problem-DASH-Video



             reply	other threads:[~2020-12-12 18:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12 18:11 Rich Brown [this message]
2020-12-12 20:50 ` David Collier-Brown

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.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5FAACDE1-CD71-4740-B56E-AAF426480827@gmail.com \
    --to=richb.hanover@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox