Project

General

Profile

Actions

Feature #12521

open

Add the BBR2, QUIC, RACK Congestion Control (CC) protocols

Added by Sergei Shablovsky about 3 years ago. Updated 11 months ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
Operating System
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default

Description

Changing character of traffic in last 5-7 years powered extremely by the fact that
- 80%+ of users using mobile devices (smartphones and tablets);
- IoT and SmartHome technologies become widely using

create request for modern, more effective Congestion Control (CC) technologies.

And this is the time where BBR2, QUIC, RACK protocols come in. Some of them already integrated in most popular nix base distributives.

Some of proofs are here https://forum.netgate.com/post/1009051 and in this tread https://forum.netgate.com/topic/163744/any-chances-to-get-netflix-s-open-connect-appliance-oca-tcp-code-rack-and-bbr-into-pfsense ==============================================================

Because the pfSense are a “heart” of any business or private network, better to add ability to be able using BBR2, QUIC, RACK protocols in a pfSense-tuned version of FreeBSD.

==============================================================
Useful Links
BBR - https://github.com/Netflix/tcplog_dumper
RACK / SACK - https://forums.freebsd.org/threads/tcp-rack-and-sack.80633/
QUIC - https://www.reddit.com/r/PFSENSE/comments/ajs0qy/quic_protocol/

Actions #1

Updated by Jim Pingle about 3 years ago

  • Priority changed from Normal to Very Low
  • Target version changed from 2.6.0 to Future

This is not a priority as those algorithms only come into play on pfSense software when the firewall is the endpoint for a connection, not when it is operating as a router.

Yes, it may affect a handful services such as HAProxy but by the time performance at that level becomes a concern an environment is well past when that should be moved to a dedicated server off the firewall at which point it again ceases to be a concern on the firewall.

VPNs rarely use TCP so they are not a factor either, if someone needs a high performance VPN it would never be using TCP.

That said, the request is also problematic in several ways:

  • QUIC is not a congestion control protocol, it uses UDP and again is between a client and a server it does not involve the firewall. To a firewall it just looks like UDP. There is nothing the firewall needs to do here. If something needs to support QUIC, that's up to the client and server software. Performance of services on the firewall again wouldn't be a factor.
  • RACK is not a congestion control protocol, it is an alternate TCP stack and requires a custom kernel on FreeBSD 13.x. I'm not sure that will be viable or desirable. Again, only relevant to endpoints and not a firewall, and since pfSense software is not yet based on FreeBSD 13.x, nothing we can do currently.
  • BBR2 doesn't appear to be available on FreeBSD in any version that I can see, but perhaps I'm not searching the right terms. You'd need to request someone implement that upstream first before it could be considered for inclusion in pfSense software if it proves to be stable in FreeBSD.

I'll leave this open for now since there may be something actionable here in the future, but there is nothing to do currently.

Actions #2

Updated by Yuran Yastreb over 2 years ago

Good afternoon!

I'm trying to test the BBR and RACK algorithms on FreeBSD v13.1 and I'm having trouble getting traffic through with the packet filter enabled.
I'll just leave a link where you can read the description of the problem:
https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093297.html

Actions

Also available in: Atom PDF