Date: Sat, 4 Nov 2023 10:20:04 +0100 From: Ronald Klop <ronald@FreeBSD.org> To: Yuri <yuri@FreeBSD.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Network starvation question Message-ID: <2baf7bc1-466c-4004-b77d-72b9fddfd6e7@FreeBSD.org> In-Reply-To: <8a967a3e-ef9c-4bc7-93e4-a5bca52ba9cf@FreeBSD.org> References: <d17ef5f2-8098-47b7-a9be-10cd8e531f91@FreeBSD.org> <CAGaXuiL1zYWqr=L8pz7xT_Etg5omedg39Cx8wJsp78ZcSJX8qg@mail.gmail.com> <8a967a3e-ef9c-4bc7-93e4-a5bca52ba9cf@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/4/23 03:37, Yuri wrote: > Router is also involved, and the provider's network as well. > > > But I think that there is a bug in the FreeBSD's network code that it allows a slower TCP connection to be hammered like this, unless there is a good explanation for this observation. > > > > Yuri > > > As you mention router and provider network are involved my first thought is bufferbloat. See https://en.wikipedia.org/wiki/Bufferbloat As UDP is involved FreeBSD doesn't do any flow control on that traffic and just sends as much as the application requests it to do. This is not a bug in FreeBSD. The design of the application is to requests FreeBSD to do this by using UDP instead of TCP. A solution to this would be to limit bandwidth of application A (mentioned in your original mail) to leave just enough space for application B to perform well. Maybe the application has support for this. Otherwise a mechanism like "dummynet" (in combination with ipfw firewall) can do this. Regards, Ronald.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2baf7bc1-466c-4004-b77d-72b9fddfd6e7>