From: Taran Lynn <taranlynn0@gmail.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] pacing, applied differently than bbr
Date: Tue, 25 Feb 2020 22:51:55 -0800 [thread overview]
Message-ID: <d7ee78e3-bf65-cb1b-8700-96240df7b521@gmail.com> (raw)
In-Reply-To: <e241935b-dd4b-4b1b-a910-6e942f5cd5af@gmail.com>
As promised, here's the updated arXiv paper on applying model predictive
control to TCP CC [1]. It contains more in depth information about the
implementation, as well as some data from physical experiments.
[1] https://arxiv.org/abs/2002.09825
On 2/9/20 8:39 AM, Taran Lynn wrote:
> Here's a paper and slides on work that has built on this research
> [1][2]. They were presented at the 2019 Buffer Workshop. A paper should
> also be posted on arXiv soon that has more details of the actual
> algorithm, which has been slightly updated since the workshop. Currently
> we're trying to improve the algorithm's performance and fairness. So far
> we've seen pretty good reductions in RTT (hopefully you'll see more
> papers in the future). We're also learning some things from BBR and the
> challenges it faced.
>
> P.S. If you're wondering why the math looks significantly different than
> in the original paper, it's because a lot of progress has already been
> made :).
>
> [1] http://buffer-workshop.stanford.edu/papers/paper14.pdf
> [2] http://buffer-workshop.stanford.edu/slides/mpc.pdf
>
> On 2/8/20 11:11 PM, Dave Taht wrote:
>> I don't know how I stumbled across this, but it seemed interesting at
>> this late hour. I wonder if they kept at it or tried ecn also.
>>
>> "A Model Predictive Control Approach to Flow Pacing for TCP"
>>
>> "we propose a different approach to latency based congestion control.
>> In particular, our controller sets the maximum pacing rate by solving
>> a model-based receding horizon control problem at each time step. Each
>> new roundtrip time (RTT) measurement is first incorporated into a
>> linear time-varying (LTV) predictive model. Subsequently, we solve a
>> one-step look-ahead optimization problem which finds the pacing rate
>> which optimally trades off RTT, RTT variance, and throughput according
>> to the most recent model. Our method is computationally inexpensive
>> making it readily implementable on current systems."
>>
>> https://people.eecs.berkeley.edu/~dfk/pdfs/network_control_camera_ready.pdf
>>
>>
next prev parent reply other threads:[~2020-02-26 6:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 7:11 Dave Taht
2020-02-09 16:39 ` Taran Lynn
2020-02-26 6:51 ` Taran Lynn [this message]
2020-02-26 20:12 ` Dave Taht
2020-03-04 8:49 ` Taran Lynn
2020-02-26 21:00 ` Jonathan Morton
2020-02-09 18:21 ` David Fridovich-Keil
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=d7ee78e3-bf65-cb1b-8700-96240df7b521@gmail.com \
--to=taranlynn0@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