BBR v1&2 use of TCP_CONG_NON_RESTRICTED

[Taran Lynn]

Hello,

Currently both BBR v1 and v2 have the TCP_CONG_NON_RESTRICTED flag set. This flag means that BBR will be added to sysctl's net.ipv4.tcp_allowed_congestion_control by default. This allows unprivileged users to set BBR as their congestion control for any of their sockets. According to the documentation (in the kernel tree Documentation/networking/ip-sysctl.txt) only Reno and the current global CC algorithm should be in tcp_allowed_congestion_control. Indeed Reno and BBR are the only CC's with this flag set.

I'm wondering if this is a bug, or if there is a valid reason for this behavior?

Best, Taran

[Neal Cardwell]

Hi Taran,

Thanks for your post!

Yes, that is intentional. The rationale is that we want to support the common use case where a system administrator running as root loads the tcp_bbr.ko module with the intent of letting users on that machine use setsockopt(...TCP_CONGESTION, "bbr"...) to set the congestion control algorithm for their connection to "bbr" (or "bbr2" for the BBRv2 alpha release). Without the TCP_CONG_NON_RESTRICTED bit being set, that use case is not allowed, so there is no way (AFAIK) for non-root users to use BBR when it's not the default, and thus no good way for them do A/B testing with BBR vs CUBIC.

It may be worth clarifying that the documentation does not say literally that "only Reno and the current global CC algorithm should be in tcp_allowed_congestion_control", but that by *default* only "reno" and the default setting are in tcp_allowed_congestion_control. That is still true, by default. But if root loads the tcp_bbr.ko module then the system enters a non-default state where "bbr" is also in the tcp_allowed_congestion_control list.

For quick reference, the version of the doc that I looked at, here:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.txt?h=v5.6#n228

says:

  tcp_allowed_congestion_control - STRING
    Show/set the congestion control choices available to non-privileged
    processes. The list is a subset of those listed in
    tcp_available_congestion_control.
    Default is "reno" and the default setting (tcp_congestion_control).

best,

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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/0158186d-6b76-4f19-8809-fa3799997506%40googlegroups.com.

[Taran Lynn]

There is a way to support that use case without setting the
TCP_CONG_NON_RESTRICTED bit. When the admin loads tcp_bbr.ko they can
also set

# OLDLIST=`sysctl -n net.ipv4.tcp_allowed_congestion_control`
# sysctl net.ipv4.tcp_allowed_congestion_control="$OLDLIST bbr"

or, more likely, explicitly set allowed CC algorithms at startup. This
will also work for any other algorithm (Vegas, BIC, etc.).

I was interpreting "Default is "reno" and the default setting
(tcp_congestion_control)" as reno and whatever
net.ipv4.tcp_congestion_control is should be the only CCs in the list
without it being explicitly changed via sysctl.

Please note that these are just observations. tbh I'm not sure what the
reasoning (or security concerns) behind not allowing users to set their
socket's CC algo was.

Best, Taran

> <mailto:bbr-dev+u...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bbr-dev/0158186d-6b76-4f19-8809-fa3799997506%40googlegroups.com

> <https://groups.google.com/d/msgid/bbr-dev/0158186d-6b76-4f19-8809-fa3799997506%40googlegroups.com?utm_medium=email&utm_source=footer>.
>