History log of /freebsd/sys/netinet/tcp_stacks/bbr.c (Results 1 – 25 of 150)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# e7fbf52a 09-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: remove dead code

No functional change intended.

Reviewed by: Peter Lei, rrs (earlier version)
CID: 1523802
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https:/

TCP BBR: remove dead code

No functional change intended.

Reviewed by: Peter Lei, rrs (earlier version)
CID: 1523802
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48341

show more ...


# 061727ef 06-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: remove dead code

No functional change intended.

Reviewed by: rrs
CID: 1523808
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48338


# c28fefe1 06-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: remove dead code

bw is unsigned and not zero. So it cannot be smaller than 1.
No functional change intended.

Reviewed by: rrs, cc
CID: 1523791
MFC after: 1 week
Sponsored by: Netflix,

TCP BBR: remove dead code

bw is unsigned and not zero. So it cannot be smaller than 1.
No functional change intended.

Reviewed by: rrs, cc
CID: 1523791
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48323

show more ...


# 4bce1a19 04-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: remove code which is not needed

rc_bbr_substate is a 3-bit unsigned int, so it can't be larger than
or equal to 8. The wrap around already happens.
No functional change intended.

Reviewed

TCP BBR: remove code which is not needed

rc_bbr_substate is a 3-bit unsigned int, so it can't be larger than
or equal to 8. The wrap around already happens.
No functional change intended.

Reviewed by: rrs
CID: 1523795
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48320

show more ...


# 305c40dc 04-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: simplify expression

There is no need to check partially for bbr->r_ctl.crte being NULL,
since this can't be true in this path.
No functional change intended.

Reviewed by: rrs
CID: 15238

TCP BBR: simplify expression

There is no need to check partially for bbr->r_ctl.crte being NULL,
since this can't be true in this path.
No functional change intended.

Reviewed by: rrs
CID: 1523810
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48312

show more ...


# 88766e7a 03-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: fix integer overflow

Use 64-bit arithmetic.

Reviewed by: rrs
CID: 1523806
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48302


# 4173a3a0 03-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: simplify expression

rsm cannot be NULL, when calling bbr_update_bbr_info().
So no need to check partially for it. No functional change intended.

Reviewed by: rrs
CID: 1523803
MFC after:

TCP BBR: simplify expression

rsm cannot be NULL, when calling bbr_update_bbr_info().
So no need to check partially for it. No functional change intended.

Reviewed by: rrs
CID: 1523803
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48293

show more ...


# c7e81cc0 02-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: do not log an uninitialized value

Reviewed by: rrs
CID: 1523789
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48281


# 1781324d 01-Jan-2025 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: remove code which is never executed

USEC_2_TICKS() returns at least 1.

Reviewed by: rrs
CID: 1523775
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://revie

TCP BBR: remove code which is never executed

USEC_2_TICKS() returns at least 1.

Reviewed by: rrs
CID: 1523775
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D4827

show more ...


# 5ec914e0 31-Dec-2024 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: fix condition when sending a tail loss probe

Reviewed by: rrs
CID: 1523793
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48274


# b47dcb4b 31-Dec-2024 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: fix getsockopt() for TCP_BBR_USEDEL_RATE

Actually implement the IPPROTO_TCP-level socket option
TCP_BBR_USEDEL_RATE.

Reviewed by: rrs
CID: 1523813
CID: 1523814
MFC after: 1 week
Spon

TCP BBR: fix getsockopt() for TCP_BBR_USEDEL_RATE

Actually implement the IPPROTO_TCP-level socket option
TCP_BBR_USEDEL_RATE.

Reviewed by: rrs
CID: 1523813
CID: 1523814
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48261

show more ...


# 895347fc 30-Dec-2024 Michael Tuexen <tuexen@FreeBSD.org>

TCP BBR: remove assignments without effect

No functional change intended.

Reviewed by: rrs
CID: 1523772
CID: 1523777
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: http

TCP BBR: remove assignments without effect

No functional change intended.

Reviewed by: rrs
CID: 1523772
CID: 1523777
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48215

show more ...


Revision tags: release/14.2.0
# 12fc7961 15-Nov-2024 Randall Stewart <rrs@FreeBSD.org>

Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK.

The socket buffer locking used to be standard on SOCKBUF_LOCK/UNLOCK. But we are now
moving to a more elegant SOCK_SEND

Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK.

The socket buffer locking used to be standard on SOCKBUF_LOCK/UNLOCK. But we are now
moving to a more elegant SOCK_SENDBUF_LOCK/UNLOCK and SOCK_RECVBUF_LOCK/UNLOCK.
Lets get BBR and Rack to use these updated macros.

Reviewed by:glebius, tuexen, rscheff
Differential Revision:https://reviews.freebsd.org/D47542

show more ...


# c9047eb7 14-Nov-2024 Richard Scheffenegger <rscheff@FreeBSD.org>

tcp: allow TSO even while RX path is unordered

Over IP networks, forward and return path largely
act independently from each other. Do not disable LRO
on the TX side, when reordering/loss is happeni

tcp: allow TSO even while RX path is unordered

Over IP networks, forward and return path largely
act independently from each other. Do not disable LRO
on the TX side, when reordering/loss is happening
on the RX half-connection.

Reviewed By: rrs, #transport, peter.lei_ieee.org
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D47056

show more ...


# 87fbd9fc 20-Sep-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: remove unused socket option names

These IPPROTO_TCP-level socket option names correspond to socket
options, which are not implemented. So remove them.
Thanks to Peter Lei for suggesting this ch

tcp: remove unused socket option names

These IPPROTO_TCP-level socket option names correspond to socket
options, which are not implemented. So remove them.
Thanks to Peter Lei for suggesting this change.

Reviewed by: rscheff, thj
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D46623

show more ...


Revision tags: release/13.4.0
# b2044c45 30-Aug-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp rack, bbr: improve handling of soft errors

Do not report an error, if it is stored as a soft error. This avoids,
for example, the dropping of TCP connections using an interface,
while enabling o

tcp rack, bbr: improve handling of soft errors

Do not report an error, if it is stored as a soft error. This avoids,
for example, the dropping of TCP connections using an interface,
while enabling or disabling LRO on that interface.

Reviewed by: cc
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D46427

show more ...


# e0b080f8 21-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: mark TCP stacks which can serve as a default stack

Allow a TCP function block (tfb) to become the default stack only if
tfb->tfb_flags has the TCP_FUNC_DEFAULT_OK flags set. This allows a
TCP f

tcp: mark TCP stacks which can serve as a default stack

Allow a TCP function block (tfb) to become the default stack only if
tfb->tfb_flags has the TCP_FUNC_DEFAULT_OK flags set. This allows a
TCP function block, that is not suitable as a default function block
to ensure that it is not set as the default via sysctl. In this case
sysctl would return EINVAL.

Reviewed by: gallatin, Peter Lei
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D45419

show more ...


# 646c28ea 21-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: improve SEG.ACK validation

Implement the improved SEG.ACK validation described in RFC 5961.
In addition to that, also detect ghost ACKs, which are ACKs for data
that has never been sent.
The ad

tcp: improve SEG.ACK validation

Implement the improved SEG.ACK validation described in RFC 5961.
In addition to that, also detect ghost ACKs, which are ACKs for data
that has never been sent.
The additional checks are enabled by default, but can be disabled
by setting the sysctl-variable net.inet.tcp.insecure_ack to a
non-zero value.

PR: 250357
Reviewed by: Peter Lei, rscheff (older version)
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D45894

show more ...


# c02a8caf 28-Jun-2024 Ryan Libby <rlibby@FreeBSD.org>

tcp_bbr: avoid gcc -Werror=pointer-to-int-cast on 32-bit arch

Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D45751


Revision tags: release/14.1.0
# fce03f85 05-May-2024 Randall Stewart <rrs@FreeBSD.org>

TCP can be subject to Sack Attacks lets fix this issue.

There is a type of attack that a TCP peer can launch on a connection. This is for sure in Rack or BBR and probably even the default stack if i

TCP can be subject to Sack Attacks lets fix this issue.

There is a type of attack that a TCP peer can launch on a connection. This is for sure in Rack or BBR and probably even the default stack if it uses lists in sack processing. The idea of the attack is that the attacker is driving you to look at 100's of sack blocks that only update 1 byte. So for example if you have 1 - 10,000 bytes outstanding the attacker sends in something like:

ACK 0 SACK(1-512) SACK(1024 - 1536), SACK(2048-2536), SACK(4096 - 4608), SACK(8192-8704)
This first sack looks fine but then the attacker sends

ACK 0 SACK(1-512) SACK(1025 - 1537), SACK(2049-2537), SACK(4097 - 4609), SACK(8193-8705)
ACK 0 SACK(1-512) SACK(1027 - 1539), SACK(2051-2539), SACK(4099 - 4611), SACK(8195-8707)
...
These blocks are making you hunt across your linked list and split things up so that you have an entry for every other byte. Has your list grows you spend more and more CPU running through the lists. The idea here is the attacker chooses entries as far apart as possible that make you run through the list. This example is small but in theory if the window is open to say 1Meg you could end up with 100's of thousands link list entries.

To combat this we introduce three things.

when the peer requests a very small MSS we stop processing SACK's from them. This prevents a malicious peer from just using a small MSS to do the same thing.
Any time we get a sack block, we use the sack-filter to remove sacks that are smaller than the smallest v4 mss (minus 40 for max TCP options) unless it ties up to snd_max (since that is legal). All other sacks in theory should be at least an MSS. If we get such an attacker that means we basically start skipping all but MSS sized Sacked blocks.
The sack filter used to throw away data when its bounds were exceeded, instead now we increase its size to 15 and then throw away sack's if the filter gets over-run to prevent the malicious attacker from over-running the sack filter and thus we start to process things anyway.
The default stack will need to start using the sack-filter which we have talked about in past conference calls to take full advantage of the protections offered by it (and reduce cpu consumption when processing sacks).

After this set of changes is in rack can drop its SAD detection completely

Reviewed by:tuexen@, rscheff@
Differential Revision: <https://reviews.freebsd.org/D44903>

show more ...


# c9cd686b 18-Apr-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: drop data received after a FIN has been processed

RFC 9293 describes the handling of data in the CLOSE-WAIT, CLOSING,
LAST-ACK, and TIME-WAIT states:
This should not occur since a FIN has been

tcp: drop data received after a FIN has been processed

RFC 9293 describes the handling of data in the CLOSE-WAIT, CLOSING,
LAST-ACK, and TIME-WAIT states:
This should not occur since a FIN has been received from the remote
side. Ignore the segment text.
Therefore, implement this handling.

Reviewed by: rrs, rscheff
MFC after: 3 days
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D44746

show more ...


# 605a0066 15-Apr-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp bbr: improve code consistency

Improve code consistency with the RACK stack.
Reviewed by: gallatin, rscheff
MFC after: 3 days
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews

tcp bbr: improve code consistency

Improve code consistency with the RACK stack.
Reviewed by: gallatin, rscheff
MFC after: 3 days
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D44800

show more ...


# dd7b86e2 18-Mar-2024 Gleb Smirnoff <glebius@FreeBSD.org>

tcp: remove IS_FASTOPEN() macro

The macro is more obfuscating than helping as it just checks a single flag
of t_flags. All other t_flags bits are checked without a macro.

A bigger problem was that

tcp: remove IS_FASTOPEN() macro

The macro is more obfuscating than helping as it just checks a single flag
of t_flags. All other t_flags bits are checked without a macro.

A bigger problem was that declaration of the macro in tcp_var.h depended
on a kernel option. It is a bad practice to create such definitions in
installable headers.

Reviewed by: rscheff, tuexen, kib
Differential Revision: https://reviews.freebsd.org/D44362

show more ...


# e18b97bd 12-Mar-2024 Randall Stewart <rrs@FreeBSD.org>

Update to bring the rack stack with all its fixes in.

This brings the rack stack up to the current level used at NF. Many fixes
and improvements have been added. I also add in a fix to BBR to deal w

Update to bring the rack stack with all its fixes in.

This brings the rack stack up to the current level used at NF. Many fixes
and improvements have been added. I also add in a fix to BBR to deal with
the changes that have been in hpts for a while i.e. only one call no matter
if mbuf queue or tcp_output.

It basically does little except BBlogs and is a placemark for future work on
doing path capacity measurements.

With a bit of a struggle with git I finally got rack_pcm.c into place (apologies
for not noticing this error). The LINT kernel is running on my box now .. sigh.

Reviewed by: tuexen, glebius
Sponsored by: Netflix Inc.
Differential Revision:https://reviews.freebsd.org/D43986

show more ...


# c112243f 11-Mar-2024 Brooks Davis <brooks@FreeBSD.org>

Revert "Update to bring the rack stack with all its fixes in."

This commit was incomplete and breaks LINT kernels. The tree has been
broken for 8+ hours.

This reverts commit f6d489f402c320f1a6eaa4

Revert "Update to bring the rack stack with all its fixes in."

This commit was incomplete and breaks LINT kernels. The tree has been
broken for 8+ hours.

This reverts commit f6d489f402c320f1a6eaa473491a0b8c3878113e.

show more ...


123456