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
next 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