From nobody Fri Nov 3 04:42:14 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SM7Q16djPz4yt8w for ; Fri, 3 Nov 2023 04:42:17 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4SM7Q064wnz4X3W for ; Fri, 3 Nov 2023 04:42:16 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 198.144.192.42 is neither permitted nor denied by domain of yuri@FreeBSD.org) smtp.mailfrom=yuri@FreeBSD.org; dmarc=none Received: from [192.168.5.3] (c-73-70-62-113.hsd1.ca.comcast.net [73.70.62.113]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 3A34gFqs046738 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 2 Nov 2023 21:42:15 -0700 (PDT) (envelope-from yuri@FreeBSD.org) X-Authentication-Warning: shell1.rawbw.com: Host c-73-70-62-113.hsd1.ca.comcast.net [73.70.62.113] claimed to be [192.168.5.3] Message-ID: Date: Thu, 2 Nov 2023 21:42:14 -0700 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "freebsd-net@freebsd.org" From: Yuri Subject: Network starvation question Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [2.62 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[yuri]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; HAS_XAW(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/23, country:US]; MIME_TRACE(0.00)[0:+]; TO_DOM_EQ_FROM_DOM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org] X-Rspamd-Queue-Id: 4SM7Q064wnz4X3W X-Spamd-Bar: ++ Hi, I've encountered the situation when the application A was using 100% of the outbound bandwidth which is approximately 3.5 MBps of UDP traffic. Then the application B (the RDP TCP connection) attempted to use a much lower outbound speed, probably < 0.5 MBps, and it got starved. Application B (RDP) was super slow as long as the application A kept running. It was almost impossible to use the RDP connection. My question is: shouldn't the system allow less intense streams to also run at a decent speed? Let's say that the outbound bandwidth threshold of the connection is 3.5 MBps. The application A can send 3.5 MBps (or more). The application B can send up to 0.5 MBps. Obviously, they can't send 4.0 MBps in total, and their speeds should be tuned down. If both of the applications would be tuned down proportionately, this could be done using the 3.5/4.0 ratio, which would be 0.875. So why then does the slower connection get slowed down so much? It was obviously slowed down many times, not just by 13%. FreeBSD 13.2 Thanks, Yuri