IETF Logo Mail Archive

Re: [tcpm] [tsvwg] "David's proposal" for cc class terms (was RE: L4S status tracking)

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Wed, 13 November 2019 20:31 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8216C12008C; Wed, 13 Nov 2019 12:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zZCRUYUJU_a; Wed, 13 Nov 2019 12:31:41 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5E112003E; Wed, 13 Nov 2019 12:31:41 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 81FAE25A1A; Wed, 13 Nov 2019 21:31:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573677099; bh=hXJdr86IdLpTxtiT9pfdeHr7btMBrcuUrTG97N80TSE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=TerpG8sti6+G0TlA9nMMxbaX4X6oIOjWZZqUQfS7nwU9TcAFhRP8Kvas3qtIUSut4 /Vk1iwPlXSGryCUC5AiQ4wW/zKMeFI7IXmkAAtTJ/ZPfZz7Cd05B9khJcvtqus/jtZ NpRWv93SXHNY/P3RHdzQ2c530aTpvEMCCx40SedU=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoAj38d_9pEb; Wed, 13 Nov 2019 21:31:38 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 13 Nov 2019 21:31:38 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 21:31:37 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Jonathan Morton <chromatix99@gmail.com>, Wesley Eddy <wes@mti-systems.com>
CC: "Black, David" <David.Black@dell.com>, Bob Briscoe <ietf@bobbriscoe.net>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S status tracking)
Thread-Index: AQHVmk7bekJMC3Uh2U2Zu9z/tPxjDKeJicYw
Date: Wed, 13 Nov 2019 20:31:37 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D501C59@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <MN2PR19MB4045EAFC55061858895E2F0983760@MN2PR19MB4045.namprd19.prod.outlook.com> <6c9a30d4-eec8-d82f-59b4-37e9f797ae91@mti-systems.com> <96111DEA-669E-47FF-B50D-B60FE59CA15E@gmail.com>
In-Reply-To: <96111DEA-669E-47FF-B50D-B60FE59CA15E@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/YnBdlBjwHmUgXUsjhEXyNACWeYc>
Subject: Re: [tcpm] [tsvwg] "David's proposal" for cc class terms (was RE: L4S status tracking)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 20:31:43 -0000

> -----Original Message-----
> From: Jonathan Morton <chromatix99@gmail.com>
> Sent: Wednesday, November 13, 2019 7:19 PM
> To: Wesley Eddy <wes@mti-systems.com>
> Cc: Black, David <David.Black@dell.com>; Bob Briscoe <ietf@bobbriscoe.net>;
> Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Rodney W. Grimes
> <4bone@gndrsh.dnsmgr.net>; tcpm@ietf.org; tsvwg@ietf.org
> Subject: Re: [tsvwg] "David's proposal" for cc class terms (was RE: [tcpm] L4S
> status tracking)
> 
> > On 13 Nov, 2019, at 7:43 pm, Wesley Eddy <wes@mti-systems.com> wrote:
> >
> > "Scalable" is the term we've been using in the L4S documents for 1/p, defined
> in l4s-arch as:
> >
> >    Scalable Congestion Control:  A congestion control where the packet
> >       flow rate per round trip (the window) is inversely proportional to
> >       the level (probability) of congestion signals.
> 
> Unfortunately, the term "scalable" sounds like a marketing term to me.  I would
> prefer to support terms with some obvious technical basis.  In my experience,
> DCTCP is closely associated with this response function, and is often used as
> shorthand for it.

At least the wording "'less unscalable' Cubic" in draft-ietf-tsvwg-ecn-l4s-id-08 is a marketing term to me. Unscalable has a negative connotation to me (as non-native speaker).

If "scalable" shall be used, IMHO a similar term with positive connotation has to be used for 1/sqrt(p) congestion control. An example would be 'high-speed congestion control' for CUBIC. That term is IMHO relatively well established in the IETF. But I am not sure if we should really go down that road.

The benefit of using terms with a technical or mathematical foundation is that we don't have to argue whether 'scalable' outperforms 'high-speed'. And I believe avoiding such controversy could help with finishing this discussion.

My 2 cents

Michael

v2.23.0 | Report a Bug | By Email