From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 3E69D3B29D for ; Sun, 19 Jun 2022 12:53:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1655657601; bh=baYmyz67OMsSQY3vPr4fHw+7Pvpsers7qmwkDdQv4kM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=P9pVtXLGULVNp/6wv1g0mMDZ/zmKBbY2H8Qm1T7f814JPJHZw3jBOPYD4rI3mQnR6 lhhjOLDKxFbq1tpXuMzUklzjkrMAVEEwn8qlKizo+l2vrbZ9y+vuxx4Q1QUHbFKuJL TmO3HEXXTt9wPyWQyI5EPx2fW/ljIIb6jfr+8sOc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([77.6.66.20]) by mail.gmx.net (mrgmx105 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4Qwg-1nb1RH2NAk-011SGc; Sun, 19 Jun 2022 18:53:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 19 Jun 2022 18:53:20 +0200 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: <7D20BEF3-8A1C-4050-AE6F-66E1B4203EE1@gmx.de> References: <6458C1E6-14CB-4A36-8BB3-740525755A95@ifi.uio.no> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.100.31) X-Provags-ID: V03:K1:Scsi7sZe5Eu65SX9XBjtr6z//5qsoGQBDMVpWrscl4netrUMv8X xBZ5sPzAvvvZdCr4bwJG67/2fl+tUL3kF094RgrFubsk/y88RF6mVauu9in03eG/xif5bXB TglfdIBWCcIi5b8kT+7gTmBgqe1i/MBVLS8q2Ty2N0EQOOSZry3ccR3KOpo06PcOOBma5qx r7MwbDlZlwWcdT1bJl5xg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:w0Ym2x64t1A=:78igki4pXQg62+jrOpjaQj IStTypTRMKVPkDm70WdT9aJWaEDKTKtYY3kPu+IDY4ixv8Whdgg9v/x5bycaVhQGnVV8XwhnH 1+LXHS/h8iMoBi6NxLJ0UcFGySqlAMtYo869JhphIqKYFeoJ4d8xNcamDSTKWiAnY29m2Z5Tb G3uq9GUBlV+tCCKGJbYISUSAFHYtP+FvuCmFpMiK5bXGYndzt44pqgq/mCuST4+6BBux3+zOO SG+iNkO37VWOMSshPnwq8X4uf6X0oQWRp528QqYjXNh7r7vtSXvFKcoDTPxtNZAiGAygIJgDK QmrM0o3Uu8KqfiXlqlr6eSM6CIG6AuLbFmEn5+66ezP3xufSo5cV2fubTXyKbwEyM9xQVj5Jz Jjfr7B9IgHPe1qE4yD7N/PuhF+qnZZ/Ms0S1tnsCIOQk1LIeD9hnPFIZ3ZehNX71Y5L1X2ReF 8JdiQw9jaWk+ZPHLir2uTtHDmo+IY4dtko/BKhXXhDV/xF/DKCVT2OwMlkF9JaWnUjfcPf7xn YWbq5kohA0LIhLE4n8CujgIgI3/JpDpGPX1IK0RSzo1RvZIAxVw1uGBpez1qSCS1Qu7f36aGm HQR8h6AhkkNupSaVQMYwcOK9an8UJ0LLLhC4vK65ND1zbI4Br1YvJ5TvLE+prUGoGYMLZO2bR bxOj/2UE33OVvib30MB/Pjrc6dSDbjY8boWLDVwMJi5vFYKCUghTI34FmCnBHw65JXJuO0AeK f276SmVULbl7fAXvGFPgOKFb3gy/1bjhs5ZrtdyilKWwPiJl/kGvxBWKLXJKZrRtOcC9dHsx6 xN272qkN+dzIm27wKIdE6rsMeW1JJBx4B1ARTiwRKjI2sF0S4HODDEQKP4UqByDzV1Z1rvHMv tatnxZBCXPE4HZRLTVPfO4RA28+rnagbQOQDGv5A2Gx6X5Cvqfw81uo9Ddo/VX8GytSuPM+df es7NocJAeaBidopsewLWKlQjBbQVtQPjYRmSO5LZ9Q2GAk3UFoKxKcb929BeiCgLyJOs1xYZ8 HYVI6vhk7emjjAJ1eanMSUtpsQVVqrnVeUJKZ9OL+ADwnf8/cys1uRiNC6+CZxIxVKWHPKp/J VTB/eQBQvoiELSDGH4uldtj+K9UEuyXEMtXYDA31kz2+ycFgPDhnAfCmQ== 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: Sun, 19 Jun 2022 16:53:23 -0000 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? > 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? 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? 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 ;) Regards Sebastian >=20 > Cheers, > Michael >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg >=20 >=20 > --=20 > FQ World Domination pending: = https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat