TCP BBR Implementation

[Fadi Al]

Hi, 

i am working on testing the TCP BBR in linux and see how it performs with sending large files of my own. is there like a client/server application which implements TCP BBR that i can use? or is it already built in into linux when i update the kernel with the TCP BBR option and any outgoing connections would you use it even if i use scp command to send files?  

Regards, 

Fadi 

[Jonathan Morton]

> On 4 Apr, 2017, at 04:50, Fadi Al <fadi...@gmail.com> wrote:
>
> i am working on testing the TCP BBR in linux and see how it performs with sending large files of my own. is there like a client/server application which implements TCP BBR that i can use? or is it already built in into linux when i update the kernel with the TCP BBR option and any outgoing connections would you use it even if i use scp command to send files?

You don’t need any special applications.

First, build the Linux kernel with BBR included. Usually, you would also include other TCP congestion control algorithms, such as CUBIC, Westwood+, and/or Reno. The default is usually CUBIC, and you could use that as your baseline.

Some applications are able to select from these by themselves, but they are usually specific benchmarking applications.

You’ll also need to build in the FQ qdisc, which BBR depends on. It’s in the “QoS / Fair Queuing” section.

To set up BBR globally, use:

sudo tc qdisc replace dev <interface> root fq pacing
sudo sysctl net.ipv4.tcp_congestion_control=bbr

…where <interface> is your LAN device. Repeat the first line for wifi or any dual-homed interfaces.

Hopefully the complication of needing the FQ qdisc (for pacing) will be eliminated sometime.

- Jonathan Morton

[Brian Tierney]

Also, if you dont want to turn it on globally for your host, iperf3 supports bbr via the " --congestion " option.

see software.es.net/iperf

[Neal Cardwell]

Jonathan Morton did a nice job of outlining the process for enabling BBR and FQ (thanks!).

There are also some specific instructions in the BBR quick-start guide:

  https://github.com/google/bbr/blob/master/Documentation/bbr-quick-start.md

In particular you want to make sure the kernel config has these options:

CONFIG_TCP_CONG_BBR=y

CONFIG_NET_SCH_FQ=y

neal

--
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shiyao Ma]

Note when you use bbr with iperf3, *both* the sender and the receiver should have *tcp_bbr* module loaded.

On the other hand, netperf allows you to use bbr on the sender, making no constraint on the receiver side.

There shouldn't make much difference on the evaluation result.  But semantically, one of bbr's advantage is cc modification only happens on server side.

[Brian Tierney]

On Tuesday, April 4, 2017 at 8:35:50 PM UTC-7, Shiyao Ma wrote:

Note when you use bbr with iperf3, *both* the sender and the receiver should have *tcp_bbr* module loaded.

I'm not aware of that constraint. Since BBR is sender side only, why would that be true?

[Bruce A. Mah]

If memory serves me right, Brian Tierney wrote:
>
>
> On Tuesday, April 4, 2017 at 8:35:50 PM UTC-7, Shiyao Ma wrote:
>
> Note when you use bbr with iperf3, *both* the sender and the
> receiver should have *tcp_bbr* module loaded.
>
>
> I'm not aware of that constraint. Since BBR is sender side only, why
> would that be true?

The iperf3 client passes the result of the --congestion parameter to the
server and the server adopts it. One reason this parameter needs to be
exchanged and set is for --reverse tests, where the server is the one
sending data.

I agree that there's no reason for the BBR module to be loaded on the
receiver side of a test, but iperf3 isn't quite smart enough to do just
the minimum amount of work. (Also, I was under the impression that
there were some cases in which the congestion control algorithm running
on the receiver could make a difference in performance, but I admit to
not knowing that for sure.)

A solution might be to add Yet Another Command Line Flag to specify the
congestion control algorithm to be used on the server, independent of
what's being used on the client, although I'm not sure how much use this
feature would get.

Is this causing a problem for testing?

Bruce.

[Drake]

Dear Jonathon,

Does it mean that if we implement the server side component (https://github.com/google/bbr/blob/master/Documentation/bbr-quick-start.md) , the client does not need to have anything special? will a web app running on such machine automatically benefit from this? Is a compliant browser required or is the local router required to allow something special?

Thanks for your inputs

On Monday, April 3, 2017 at 7:37:17 PM UTC-7, Jonathan Morton wrote:

[Jonathan Morton]

That's right, only the sending machine needs to be set up with BBR. Commonly that is the server, although in some applications a lot of data also comes from the client. In those cases the uploaded data will still use whatever congestion control algorithm the client has.

- Jonathan Morton

[Drake]

Thanks Jonathan for the quick revert.

Summarizing ( Please correct my understanding)

A) Server side:

     Linux- BBR implementation as per info given on this page

     Windows- i am not aware if there is a way to implement this on windows. Pls correct me if wrong.

B) Client side (Normally no action required except when we want to optimize client side owing to large upload):

     WebApp- is the change required to be done at machine level? if no, then please provide link of any sample implementation

     Desktop app- Any link to help with implementation

     Mobile- Any link to help with implementation

Thanks

A) Server side:

A) Since mostly we are talking about web apps,  eve

[Jonathan Morton]

I'm also not aware of any way to implement BBR on Windows, whether client or server editions. You should expect to see NewReno or Compound TCP in use there.

It's also most likely unfeasible to expect average users to have BBR, at least in the near to medium term. This is deep system level stuff and can't really be done at application level, unless you're building your own reliable transport layer on top of UDP; it's certainly not web app client material.

- Jonathan Morton