From nobody Fri Nov 03 11:53:12 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 4SMJzW1dSLz4yrpv for ; Fri, 3 Nov 2023 11:53:27 +0000 (UTC) (envelope-from ccfreebsd@gmail.com) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SMJzV6mZBz4Qky; Fri, 3 Nov 2023 11:53:26 +0000 (UTC) (envelope-from ccfreebsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2c6efcef4eeso23064961fa.1; Fri, 03 Nov 2023 04:53:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699012404; x=1699617204; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4E/xYCSoeI9kvO9cIEuOGNlLzS5mCA3hTNMFGrogRcI=; b=ZQIsPr8y3eNIrWC/bwxvqUN2QW/711Hla/6ajmOMNUnAtbg0q2f02XBEGQLFczhW0C ZK5yWof6CG1oN6nPZscVHqT/S/h5iPuXBFbnxGZQw37kqa2RqnAP+RxXl+9+4PvgpjKy 6Ci0KouSVkUf61JL77ALGZZNVdLyiwdNHLAkkrT/rDtEkPJj7N12ibyOHw3CCK2BKdLa uZa4Q3OChAhGXSi74HNC2eaXJ8CzFQx2RE+7m8kdqsmuXY/RRSUoTgz6QQfBXX3c+5ao 0w7IKJAXW/s0d16FCN+koKhvsme9y7hB3KE/HHTUZYT5rBNHoQCYKWkqqHpjywno5dJD WS7Q== X-Gm-Message-State: AOJu0YzelXhZUueXvXYChi1DKUdMwLFmDi93M/X9wqEe0BaquotCVsoN LW9YAe2xNDwzd5nIS74QSQpnHY3s54Ruvg== X-Google-Smtp-Source: AGHT+IE2+UQ1qFFpHyh2Ojd+7y1HWrsl/9xKP0KCkG5bagnm4Uu64+ho4V2sbqsnGI2OPu8MbsVvng== X-Received: by 2002:a2e:b953:0:b0:2c5:2d02:ed14 with SMTP id 19-20020a2eb953000000b002c52d02ed14mr15834910ljs.23.1699012404200; Fri, 03 Nov 2023 04:53:24 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id x22-20020a2e9c96000000b002c02cf6cac5sm216473lji.83.2023.11.03.04.53.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Nov 2023 04:53:24 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-507975d34e8so2746893e87.1; Fri, 03 Nov 2023 04:53:23 -0700 (PDT) X-Received: by 2002:a05:6512:4850:b0:507:97ca:ec60 with SMTP id ep16-20020a056512485000b0050797caec60mr15509021lfb.3.1699012403774; Fri, 03 Nov 2023 04:53:23 -0700 (PDT) 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 References: In-Reply-To: From: Cheng Cui Date: Fri, 3 Nov 2023 07:53:12 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Network starvation question To: Yuri Cc: "freebsd-net@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000cbcd2806093e26e9" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4SMJzV6mZBz4Qky --000000000000cbcd2806093e26e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yuri, If I understand your situation correctly, your application A is using UDP but application B is using TCP and the max outbound bandwidth is < 4MBps. If A can send at 3.5 Mbps and B can send at 0.5 Mbps, why B is suffering more in throughput when the outbound limit is < 4Mbps? There are many factors I think in my experience that can contribute to this= . But maybe we prefer a solution rather than the root cause of the difference= . If you can tune A to use less bandwidth and let B to use the full 0.5 Mbps, the problem may be solved. (for example, iperf default in UDP is ~1Mbps but can be tuned to send at max bandwidth, so vice versa) Then, back to the possible contribution factors of TCP suffering from a UDP traffic competition : 1. UDP traffic rate can be considered constant so it does not yield 2. TCP congestion control may be encountered 3. application's responsiveness may be different Best Regards, Cheng Cui On Fri, Nov 3, 2023 at 12:42=E2=80=AFAM Yuri wrote: > 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 > > > > --000000000000cbcd2806093e26e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yuri,

If I understand you= r situation correctly, your application A is using UDP but
applic= ation B is using TCP and the max outbound bandwidth is < 4MBps.

If A can send at 3.5 Mbps and B can send at 0.5 Mbps, why = B is suffering
more in throughput when the outbound limit is <= 4Mbps?

There are many factors I think in my exper= ience that can contribute to this.
But maybe we prefer a solution= rather than the root cause of the difference.
If you can tune A = to use less bandwidth and let B to use the full 0.5 Mbps,
the pro= blem may be solved. (for example, iperf default in UDP is ~1Mbps but
<= div>can be tuned to send at max bandwidth, so vice versa)
Then, back to the possible contribution factors of TCP sufferin= g from a UDP
traffic=C2=A0competition :
  1. UDP= traffic rate can be considered constant so it does not yield
  2. T= CP congestion control may be encountered
  3. application's resp= onsiveness may be different

Best R= egards,
Cheng Cui


On Fri, Nov 3, 2023 at 12:= 42=E2=80=AFAM Yuri <yuri@freebsd.org= > wrote:
= 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 b= e
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



--000000000000cbcd2806093e26e9--