Re: [iccrg] Musings on the future of Internet Congestion Control

Michael Welzl <michawe@ifi.uio.no> Thu, 16 June 2022 08:49 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B04C15B268 for <iccrg@ietfa.amsl.com>; Thu, 16 Jun 2022 01:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbXFshb1Nbta for <iccrg@ietfa.amsl.com>; Thu, 16 Jun 2022 01:49:11 -0700 (PDT)
Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2748BC15B265 for <iccrg@irtf.org>; Thu, 16 Jun 2022 01:49:10 -0700 (PDT)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <michawe@ifi.uio.no>) id 1o1lBV-003gUz-Dv; Thu, 16 Jun 2022 10:49:01 +0200
Received: from 243.212-33-148.static.xfiber.net ([212.33.148.243] 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 <michawe@ifi.uio.no>) id 1o1lBU-000EGv-Iy; Thu, 16 Jun 2022 10:49:01 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <c190eec1-08b1-7a01-869f-c4e16b0fb19a@huitema.net>
Date: Thu, 16 Jun 2022 10:48:57 +0200
Cc: iccrg@irtf.org, 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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6364A590-C9FC-4216-947F-033ED081C5C8@ifi.uio.no>
References: <6458C1E6-14CB-4A36-8BB3-740525755A95@ifi.uio.no> <c190eec1-08b1-7a01-869f-c4e16b0fb19a@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3696.100.31)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 212.33.148.243 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.33.148.243; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 5C8954D0EB2C8B60D083E5C6959D350911083B15
X-UiOonly: 799FADE5502F27863D492B32DAC99CEEDC0AD4A4
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/271gmzbnbaTBaYWwUrDaKN-Rrwc>
Subject: Re: [iccrg] Musings on the future of Internet Congestion Control
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2022 08:49:15 -0000

Hi Christian!

I definitely think that work like this is the way to go - as capacities become less and less utilized, we should probably make congestion controls a bit more “daring”.

As a side note, your email made me check if RFC 9040 is cited  ;-)   and it is… but the way the reference is written in section 3.4 gives the impression that RFC 9040 only discusses the case of concurrent connections, which it doesn’t (it’s one half of the RFC, called “ensemble sharing" - the other half is “temporal sharing”). I think it would make sense to update this text a little.

Generally, for anyone who think that something in particular should have been referenced in our paper, please note that IEEE Communications Magazine only allows 15 references.  We DID want to cite, and talk about much more. We’re also in the order of 10 words or so below the word limit.

Cheers,
Michael


> On Jun 16, 2022, at 5:57 AM, Christian Huitema <huitema@huitema.net> wrote:
> 
> Michael,
> 
> Your paper mentions the issue of "not being able to ramp up capacity quickly enough". There has been quite a bit of attention to that in the context of satellite networks, leading for example to https://datatracker.ietf.org/doc/html/draft-kuhn-quic-careful-resume-01.html -- basically, remember network conditions from previous connections and use them cautiously to ramp up congestion control faster. Maybe worth mentioning in follow-up papers.
> 
> -- Christian Huitema
> 
> On 6/15/2022 1:02 AM, Michael Welzl wrote:
>> 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 <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”: 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?
>> 
>> Cheers,
>> Michael
>> 
>> 
>> 
>> _______________________________________________
>> iccrg mailing list
>> iccrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/iccrg