From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 15CAE3B29E for ; Mon, 20 Jun 2022 08:58:24 -0400 (EDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o3Gyy-00FRzu-PF; Mon, 20 Jun 2022 14:58:20 +0200 Received: from vpn-client469.uio.no ([193.157.137.216] helo=smtpclient.apple) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1o3Gyx-000GJq-6R; Mon, 20 Jun 2022 14:58:20 +0200 From: Michael Welzl Message-Id: <4E163307-9B8A-4BCF-A2DE-8D7F3C6CCEF4@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_39AF6728-4715-4E3C-9650-6CBB43E833ED" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Date: Mon, 20 Jun 2022 14:58:17 +0200 In-Reply-To: <7D20BEF3-8A1C-4050-AE6F-66E1B4203EE1@gmx.de> Cc: Dave Taht , bloat To: Sebastian Moeller References: <6458C1E6-14CB-4A36-8BB3-740525755A95@ifi.uio.no> <7D20BEF3-8A1C-4050-AE6F-66E1B4203EE1@gmx.de> X-Mailer: Apple Mail (2.3696.100.31) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 193.157.137.216 is neither permitted nor denied by domain of ifi.uio.no) client-ip=193.157.137.216; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 93D7A1297532612B76F360C42C605588C3775A9F X-UiOonly: 97132B119E65DF35FC8DB2D90B0DDEE4447A8BC9 Subject: Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2022 12:58:24 -0000 --Apple-Mail=_39AF6728-4715-4E3C-9650-6CBB43E833ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 19, 2022, at 6:53 PM, Sebastian Moeller via Bloat = wrote: >=20 > I might be out to lunch here, but why not accept a "total" speed limit = per TCP flow and simply expect bulk transfers to employ more parallel = streams; which is what I think download manager apps are already doing = for a long time? >=20 > And if we accept an upper ceiling per TCP flow we should be able to = select a reasonable upper bound for the initial window as well, no? Using multiple flows is a way to do it, albeit not a very good way = (better to use a better congestion control than just run multiple = instances - but of course, one works with what one can - a download = manager is on the receiver side and can achieve this there). This is not = related to the IW issue which is relevant for short flows, which are the = most common type of traffic by far (a point that our paper makes, along = with many prior publications). >> On Jun 15, 2022, at 19:49, Dave Taht via Bloat = wrote: >>=20 >> ---------- Forwarded message --------- >> From: Michael Welzl >> Date: Wed, Jun 15, 2022 at 1:02 AM >> Subject: [iccrg] Musings on the future of Internet Congestion Control >> To: >> Cc: Peyman Teymoori , Md Safiqul Islam >> , Hutchison, David = , >> Stein Gjessing >>=20 >>=20 >> Dear ICCRGers, >>=20 >> We just got a paper accepted that I wanted to share: >> Michael Welzl, Peyman Teymoori, Safiqul Islam, David Hutchison, Stein >> Gjessing: "Future Internet Congestion Control: The Diminishing >> Feedback Problem", accepted for publication in IEEE Communications >> Magazine, 2022. >>=20 >> The preprint is available at: >> https://arxiv.org/abs/2206.06642 >> I thought that it could provoke an interesting discussion in this = group. >>=20 >> Figures 4 and 5 in this paper show that, across the world, network >> links do not just become "faster=E2=80=9D: the range between the low = end and >> the high end grows too. >> This, I think, is problematic for a global end-to-end standard - = e.g., >> it means that we cannot simply keep scaling IW along forever (or, if >> we do, utilization will decline more and more). >>=20 >> So, we ask: what is the way ahead? Should congestion control really >> stay end-to-end? >=20 > Do we really have any other option? It is the sender that = decides how much to dup into the network after all. Sure the network = could help by giving some information back as a hint (say a 4bit value = encoding the maximum relative queue-fill level measured along the full = one-way path) but in the end, unless the network is willing to police = its idea about acceptable send behavior it is still the sender's = decision what tho send when, no? In a scenario where a connection-splitting PEP is installed before a = lower-capacity downstream path segment, this PEP can already ask for = more data today. It=E2=80=99s doing it in an ugly way, by = =E2=80=9Ccheating=E2=80=9D TCP, which yields various disadvantages=E2=80=A6= so I=E2=80=99d say that this is part of the problem. PEPs exist, yet = have to do things poorly because they are treated as if they shouldn=E2=80= =99t exist, and so they become unpopular for, well, having done things = poorly... > Given the discussion about L4S and FQ it seems clear that the = "network" is not prepared to implement anything close to what is = required to move congestion control into the network... I have a feeling = though that I am missing your point and am barking up the wrong tree ;) I guess you are. This is about middleboxes doing much =E2=80=9Cheavier=E2=80= =9D stuff. Cheers, Michael --Apple-Mail=_39AF6728-4715-4E3C-9650-6CBB43E833ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 19, 2022, at 6:53 PM, Sebastian Moeller via Bloat = <bloat@lists.bufferbloat.net> wrote:

I might be out to lunch here, but why not accept a "total" = speed limit per TCP flow and simply expect bulk transfers to employ more = parallel streams; which is what I think download manager apps are = already doing for a long time?

And if we accept an upper ceiling per TCP flow we should be = able to select a reasonable upper bound for the initial window as well, = no?

Using = multiple flows is a way to do it, albeit not a very good way (better to = use a better congestion control than just run multiple instances - but = of course, one works with what one can - a download manager is on the = receiver side and can achieve this there). This is not related to the IW = issue which is relevant for short flows, which are the most common type = of traffic by far (a point that our paper makes, along with many prior = publications).


On = Jun 15, 2022, at 19:49, Dave Taht via Bloat <bloat@lists.bufferbloat.net> wrote:

---------- Forwarded message ---------
From: = Michael Welzl <michawe@ifi.uio.no>
Date: Wed, Jun 15, = 2022 at 1:02 AM
Subject: [iccrg] Musings on the future of = Internet Congestion Control
To: <iccrg@irtf.org>
Cc: Peyman Teymoori <peymant@ifi.uio.no>, Md Safiqul Islam
<safiquli@ifi.uio.no>, Hutchison, David <d.hutchison@lancaster.ac.uk>,
Stein = Gjessing <steing@ifi.uio.no>


Dear ICCRGers,

We just got a = paper accepted that I wanted to share:
Michael Welzl, = Peyman Teymoori, Safiqul Islam, David Hutchison, Stein
Gjessing: "Future Internet Congestion Control: The = Diminishing
Feedback Problem", accepted for publication in = IEEE Communications
Magazine, 2022.

The preprint is available at:
https://arxiv.org/abs/2206.06642
I thought = that it could provoke an interesting discussion in this group.

Figures 4 and 5 in this paper show that, = across the world, network
links do not just become = "faster=E2=80=9D: the range between the low end and
the = high end grows too.
This, I think, is problematic for a = global end-to-end standard - e.g.,
it means that we cannot = simply keep scaling IW along forever (or, if
we do, = utilization will decline more and more).

So, = we ask: what is the way ahead? Should congestion control really
stay end-to-end?

Do we really = have any other option? It is the sender that decides how much to dup = into the network after all. Sure the network could help by giving some = information back as a hint (say a 4bit value encoding the maximum = relative queue-fill level measured along the full one-way path) but in = the end, unless the network is willing to police its idea about = acceptable send behavior it is still the sender's decision what tho send = when, no?

In a = scenario where a connection-splitting PEP is installed before a = lower-capacity downstream path segment, this PEP can already ask for = more data today.  It=E2=80=99s doing it in an ugly way, by = =E2=80=9Ccheating=E2=80=9D TCP, which yields various disadvantages=E2=80=A6= so I=E2=80=99d say that this is part of the problem. PEPs exist, yet = have to do things poorly because they are treated as if they shouldn=E2=80= =99t exist, and so they become unpopular for, well, having done things = poorly...


Given the discussion about L4S and FQ it seems clear that the = "network" is not prepared to implement anything close to what is = required to move congestion control into the network... I have a feeling = though that I am missing your point and am barking up the wrong tree = ;)

I = guess you are. This is about middleboxes doing much =E2=80=9Cheavier=E2=80= =9D stuff.

Cheers,
Michael

= --Apple-Mail=_39AF6728-4715-4E3C-9650-6CBB43E833ED--