IETF Logo Mail Archive

Re: [iccrg] [tsvwg] New Internet Draft: Congestion Signaling (CSIG)

Sebastian Moeller <moeller0@gmx.de> Thu, 14 September 2023 06:58 UTC

Return-Path: <moeller0@gmx.de>
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 25B8FC151091; Wed, 13 Sep 2023 23:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.853
X-Spam-Level:
X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de
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 gQFciomCZq7F; Wed, 13 Sep 2023 23:58:13 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708B0C14CE3F; Wed, 13 Sep 2023 23:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1694674689; x=1695279489; i=moeller0@gmx.de; bh=z1FHbzwZZKGXNbCGWUrR9dFj8Mziry+31p2YeGdS3pU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KsHLqoNyyMLt6e2FaB/nrhUtI0lM7Kvylfn9ZJi2Q1GNfqKhSrlui0d4LVlIfS5a+sosZPM6v4d UB4sjrBV3/P9YRHIQERPjTw/c4wQ6OuKCFR3NOqZI1wEoZyUgB1tQWzOnewPbwWh0qdCJrH5cCTT+ nQuz6zcRm3AF6kTyINCmKojCkcU3srRVJW0E4sabZAJHBMZhWplG3se/0lG47+cmmOG8StMV9qhRd 01aG8xXNEwTCxHoJmDly/yevh+H9eFyL6RLA46dPUlm3V8REEYxMo7DVuMin+3qbc81tBz3gJ2HrQ 8CczKdHdA6ft5sdMZvB9G2CmcIA9Z6JlDquA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MF3DM-1qw3SK479E-00FRj2; Thu, 14 Sep 2023 08:58:09 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <CAF0+TDB5Vt-LXGyvMiuYiuBOe2mL6OzSTYd5FgVh2he9LWd1Vw@mail.gmail.com>
Date: Thu, 14 Sep 2023 08:58:08 +0200
Cc: tsvwg <tsvwg@ietf.org>, IETF IPPM WG <ippm@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, ccwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <70050AA9-B009-43C1-9A6F-68B65FEB053C@gmx.de>
References: <92a6a6b54105447db6998d15961b1f8e@huawei.com> <2cc3f954aa2447dcb475f2a630841859@huawei.com> <2F15B386-EFF2-4637-8A3D-AF3CDD61114D@apple.com> <AM8PR07MB8137B5059D94432D3963BD1CC2F0A@AM8PR07MB8137.eurprd07.prod.outlook.com> <B31F8A17-D540-46E3-9759-0FA10DA49A03@gmx.de> <FR2P281MB15279F01E5441F13540879889CF0A@FR2P281MB1527.DEUP281.PROD.OUTLOOK.COM> <CAF0+TDB5Vt-LXGyvMiuYiuBOe2mL6OzSTYd5FgVh2he9LWd1Vw@mail.gmail.com>
To: Abhiram Ravi <abhiramr@google.com>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
X-Provags-ID: V03:K1:i77SeG3ZRAsPhZY0ReiY8B64qv3q1Ld1ECVUhQ87BeHh3wlgEBA xD//e88H682eK5Z+gCNjpSTUS6mgo3MWS7JQEskXz4AxAOVkJEkyX3nMYWRSa+CLWkgtD+o oqEyGdzsPtbLKFoy6JEC0BwMpG4SpadOPm+h2dqLtGluZe6ntn3lo+cGXrysD7HdUEouRz8 c0yA2pr4kkO0kOpqw8GoA==
UI-OutboundReport: notjunk:1;M01:P0:AVIRGD2ROqM=;uD1Yc9EmcbUuPBlW5udCQ4Jydhh C3ILZIhlMnfo3nFmEFTD8y/8YNQ8FiyoKwfZmltmVQxF3ya1M2hirhWvbJ3ICpDxdggd+3H2v lXrQ39Ys/tdZ32S4df/7qxrvyJRfgZa/EecT4FzQavdkGjDNvYJB0pzwH36gqw2ivLs5aapgo Yl68EP56YgMInsUm3FrSIdVl3hz5g4sWKcFANuVWIJRT7H8GFK5/jjqhfDuEI243g842LGCbx qokcgc/IN44d79vned4XIUvpTiEOFLw+ubaZwa25WIRL0o5SwoEWSnH9G8yISLOEEE8FRTUcR REp75tm5rAwvfqaR//cS5B9Auf356YLjauLXbeNdnqVCf15KWo9j9DtnyuvZiKMEF3GKGFIIj k3TPgkuHYKz0jlG+DMXH9igelaIQ96JFtwfOZ3HTOG3rB8RvOu2tmDS/E03ZZT6/Ladkw2M+B UQh6hHKHS0833rITMLetV+mxf9quyZoSrMzaTwEd99KwRMbH4FBVkkQT5gMlkhdzrlumcCamU pFOjk7wNmECOAQdi+OzxLPc2ljQctevBle/9TmGaidrBcSaUd0XVq5AjvMBAyGEcvBD/+yXCG kLCwOiEaNRimirhXga3AR2dPOdBEL05k4UxMmDZEOoVWFt4ypp7BskCE06LJpgMvaXPJerl1A h1IsAnm0koUS6fZXf6DG/V2ck/fOhu54iGVg2S72kKaWotokvzNBXnNn1hDeYmcLeSLsSNcZV 8xqV2Y+AojfrZB/UIol43ISolqrqPp28DJSq5Rhl/B6EflY9vn6nLa9YT3/emef9GpeO4X9GJ n7YqNnQZ/nMnsYNylewSHiQvBtdLe4pjhKtfmduraoeV/k+ZSVtYChqLui7xlA/GJmn3YdclY m/9xkXeBMbx8k65RG9WIJlJZYrdK873dbPZNrMhlWBd479UjL24z3rVJONrthbGjOp4SQbrPS LPfoB2kO4qgiaeSCVwlJhYjgfzs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/8X_ArjCJTmTViyj9ETzPWwgsUgQ>
Subject: Re: [iccrg] [tsvwg] New Internet Draft: Congestion Signaling (CSIG)
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, 14 Sep 2023 06:58:17 -0000

Hi Abhiram,

I shortened the CC list to avoid mandatory moderation as I an not subscribed to all of the list, I hope this is OK. Please see {SM} below.

> On Sep 14, 2023, at 02:07, Abhiram Ravi <abhiramr@google.com> wrote:
> 
> Thank you for your comments. Responses inline.
> [...]
> 
> > Sebastian: What happens if bottlenecks hand out immediate capacity/rate estimates and all greedy flows start increasing their cwin really fast?
> 
> CSIG supports both min(ABW) and min(ABW/C). Using min(ABW/C), the each flow can increase its rate in proportion to the % available bandwidth, so that in aggregate the flows respect the available bottleneck bandwidth with reduced risk of overshoot. See Section 8.1.2. 
> 
> [...]


[SM] Thanks! I was thinking this was intended to be an absolute solution, but reading 8.1 and your reply makes me realize the core is significant risk reduction. Since perfect is often not achievable I think this is a worthwhile improvement. This still leaves issues with uncoordinated flows hammering a link that can result in transiently increased queuing delay, but since each flow would (hopefully) limit its slow-start up to reaching a cwin appropriate for the total available path capacity that would still be a clear win over the status quo with TCP.
It is however unfortunate that this is not going to be usable over the internet any time soon...

Regards
	Sebastian

v2.23.0 | Report a Bug | By Email