Re: [tsvwg] L4S vs SCE (Evolvability)

"Black, David" <David.Black@dell.com> Wed, 01 January 2020 23:33 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA0C12004C; Wed, 1 Jan 2020 15:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=cM8Aib/N; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=n99H02Xb
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 Xl69bqwa1FqS; Wed, 1 Jan 2020 15:32:58 -0800 (PST)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DAE12000F; Wed, 1 Jan 2020 15:32:58 -0800 (PST)
Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 001NSKle002702; Wed, 1 Jan 2020 18:32:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=Hl9CCUzzFrXdogl/NwMxapGKDQQaOAc4MHKFYOOTDLs=; b=cM8Aib/NgxS+LWTsJ9ijJzLbBCNepL9ioV2aFN8McrQ5t5+U/JVt3jPK7zT0qJDXTkUt DO6W0/BZzXizveAntHKi68wFPP/SPYaYEzlpHoJ2xAyRLylC0NNsw+Dmq/lPSMf0n5I/ gfxMld8MLHPxQ6y43H4z2r154FHEUT7NExW5BdbrgeIYkKne2emFEoo54p0i5K9o4Xbs MmxmW/sQK/4nu1k+R8z8N8oQ8u1k9P94up99PS5Ei4N8DxiYBGiGkP5Gu5ml3N71Lbge ioU3tLB4U8ZMxMh1w78yCeKiZwgL+fK8oNFCtzXjKVYAGXFH+0ng4UeYiL8NyxH8tD+Z aw==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2x63075sre-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Jan 2020 18:32:11 -0500
Received: from pps.filterd (m0133268.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 001NJpki012042; Wed, 1 Jan 2020 18:32:11 -0500
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) by mx0a-00154901.pphosted.com with ESMTP id 2x625vjf6n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 01 Jan 2020 18:32:11 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hs56SOr6XmL6xs31tx6tj/CFOG41o4wEd9yks/yKv/gFKZ1u4LafJvlbSuma4QGrSXEX6tzg/2wk1FCRNAq18SZM3IPkmaTY6iolN4izbTTMbQOOMJkz18b2bmfHg2R/AwxOCYAJftO1xQt0jKA9zs1WgIOprcjEwP0SOyidTUrJ5gO/V7l6yXWdIHhMg40nrFWAO7fTDoes8Zp4ePfrtPhUatyPlajmcUslQjkVWX+LBckINzxVQzbkjk9B0TU5nSFRAZPqh2RY9BNciBUJQZAAjrVsIbEny+dBRQMXwD+Snk13BZiBXBiC0W/TUOAhl6/nrDcLxfeG8WN1nXNwvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hl9CCUzzFrXdogl/NwMxapGKDQQaOAc4MHKFYOOTDLs=; b=hikilZcsEBQGaB2zukpRWgNmoUN9kZdGcOIeqifHhsl7BjibFJ76Ybs7Gylvt3saPFTcEFurbUys6pvG37V9sUwgS5abpaFxP8A8Zjngi3oCg7TM8CYX2K1QNPgCoSTRHPZUSPCJukHCFqtBVECWw2OlteMFUWKTiie/CAfT4/JlykHuXrChqOxBJsQ36lxoQRGTy2qMpWPqzF/Sxr5dRSMagzOKLM4P3wxTym1u/00vQ8ihZbj8jSxbJYxn7O5JAb9WIhodvumNfJIg4tq44Q66jnOQ1gII7wBEDslyrpPvauViKXn3V3khqIqUF5XuStUY0CSXgXcZP0Mk3UMHRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hl9CCUzzFrXdogl/NwMxapGKDQQaOAc4MHKFYOOTDLs=; b=n99H02Xbqk/PTtsgPsnr6yLJVHDSq2zCjHHugDpqbNrLA+lK0fGMUctS7jg9fkmtbgm0LcXeQ2wNiLHPfiy20b1LujbViCvnecq2fACO0abCzAm40L5SYwR5iE3CdwbvSUxOQv7vvPHPvwBVoeU0BBADu2AxLJR9mf3b/oWvCUs=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB3758.namprd19.prod.outlook.com (10.186.145.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Wed, 1 Jan 2020 23:31:59 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::58e:e637:6650:64ab]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::58e:e637:6650:64ab%3]) with mapi id 15.20.2602.012; Wed, 1 Jan 2020 23:31:59 +0000
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, Roland Bless <roland.bless@kit.edu>
CC: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Kyle Rose <krose@krose.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] L4S vs SCE (Evolvability)
Thread-Index: AQHVwC+kCSTqKsezvkOgjNh+yWnZaafWdJ5w
Date: Wed, 1 Jan 2020 23:31:59 +0000
Message-ID: <MN2PR19MB404595E43875C2DD459A5C9283210@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <1ed5e25f-d105-8866-99fb-5fce181bbbbe@kit.edu> <5d36ceb0-d03f-6fee-c7ea-e803fbfa606f@bobbriscoe.net> <151fd71f-bdc5-a140-104f-e924a2b7dc16@kit.edu> <1943e190-a4c7-bafb-3c4d-5aaedfb55bd6@bobbriscoe.net>
In-Reply-To: <1943e190-a4c7-bafb-3c4d-5aaedfb55bd6@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-01-01T23:31:57.6382640Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [128.221.224.208]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: db089d0f-3db6-4acf-be0c-08d78f12cc1b
x-ms-traffictypediagnostic: MN2PR19MB3758:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB375879E62FDEFD6B54D150A783210@MN2PR19MB3758.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02698DF457
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(376002)(136003)(13464003)(7502003)(52314003)(189003)(199004)(52536014)(55016002)(30864003)(66574012)(71200400001)(66556008)(64756008)(66446008)(66946007)(66476007)(9686003)(76116006)(5660300002)(26005)(8936002)(81156014)(2906002)(81166006)(86362001)(54906003)(110136005)(33656002)(786003)(4326008)(316002)(53546011)(7696005)(107886003)(6506007)(186003)(8676002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3758; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1CXmRnOXbVeqGza2/2dFHwU7xmarD5+2PHKFEQ3yKIfHqsqauWsmO1I7iXodYo37ojmtWO377XBRgRFWkL0Yb9bZNUXwyYaT6R+Lq0ren67OxB94WJx7DgMz8laZmpl+N4A5WhTEP/19knEsGl4R1irKut4/bZeX2UQ0BxA1o4wjrcNQoJfYMAjvO5VCCBrSXTQiIJp9dDbpDyEfiEhRz/vi/mA6OVNYpgpLwbMWNOcZFPMQlbiTS1Z9NeNg7z9udQDC20X2tZ9U/KwKv8pffrXDofbKu9A0v7kAFgs/ZV+RsRTxwx3bAcW0bxwNHk4l9DaSOsK/sBT19MRk2VD22FQFQRhbWtbt7EOdM+YSlGB5pGGOozZtBYi2rhf0qAcCIobAssBSxOBwIf5i4GdruAzviZTiao3tO0jSaKpnP58jwh+Ka+UQ+hrgBk1d55Ant5exB+OoLP1PTqpArhGuBW0K4Cn2uf8d/n1VkTjr8Im7DFRwYMsGBrMl3fqvVNuSVCmljg8T0uRfUiKwl51VZcrRSOAwrVHCSGdOYAv7K1tH3zlMF9Wj1qt5+wSzNvm1VpEnKQEi+nwpzIw/2xz3xg==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: db089d0f-3db6-4acf-be0c-08d78f12cc1b
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2020 23:31:59.1224 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eGfwLwn8aPBmf3Yt2oCnGlZGavYZoSdHOImkvw4Jjvs9uubLVqvLLkX3d9Ah/tYGv0EMwXizXTXVMVMPuhmVzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3758
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-01_07:2019-12-30,2020-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0 clxscore=1011 suspectscore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 phishscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001010215
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 impostorscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 suspectscore=0 phishscore=0 mlxscore=0 clxscore=1015 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001010216
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TNYbWctdjph-KdJIq6h0uWyUGE0>
Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jan 2020 23:33:01 -0000

Bob,
(posting as an individual)

The assertion that SCE traffic will "starve" is just plain wrong in the following ...

> > The SCE markings can be used independently whether you have multiple
> > queues or just a single queue.
> [BB] This seems to be the opposite of reality. Perhaps you've used the
> word 'can' because you think it might be possible. But there's good
> reason to doubt that. As follows...
> 
> Packets from non-SCE and from SCE senders are indistinguishable by just
> looking at them. So, if there's a single queue, they have to be mixed
> together in it {Note 1}. But a single queue can only have one length.
> Any transports that don't understand SCE drive the single queue to a
> deeper operating point (defined by CE or drop).

The reasoning appears to be sound up to this point, but the next sentence does not follow from the above:

> This overruns the SCE
> operating point, and causes SCE marking to approach 100% {Note 2}. Then
> those transports that do understand SCE will starve.

Actually, it causes both SCE and non-SCE senders to operate at that "deeper operating point (defined by CE or drop)" because SCE traffic has an RFC-3168-like response to CE marks, and the usual reaction to drops.  The result is a deeper queue than would have resulted in the absence of non-SCE traffic, but the result is definitely *not* starvation.

Thanks, --David

> -----Original Message-----
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, December 31, 2019 6:11 PM
> To: Roland Bless
> Cc: De Schepper, Koen (Nokia - BE/Antwerp); Ingemar Johansson S; Kyle
> Rose; tsvwg@ietf.org; tsvwg-chairs@ietf.org
> Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
> 
> 
> [EXTERNAL EMAIL]
> 
> Roland,
> 
> As I just said, I noticed that Koen's useful response snipped some of
> your responses about evolvability that I ought to have addressed.
> Sorry, you'll need to reload state from November...
> 
> On 22/11/2019 02:32, Roland Bless wrote:
> > Hi Bob,
> >
> > see inline.
> >
> > On 21.11.19 at 15:44 Bob Briscoe wrote:
> >> Roland,
> >>
> >> I'm not getting it....
> >>
> >> On 21/11/2019 09:32, Roland Bless wrote:
> >>> Hi Bob,
> >>>
> >>> see inline.
> >>>
> >>> On 21.11.19 at 19:34 Bob Briscoe wrote:
> >>>> On 20/11/2019 21:22, Roland Bless wrote:
> >>>>> Yes, but as I also expressed my concerns w.r.t. the L4S codepoint
> >>>>> earlier, at the cost of binding this to a quite fixed set of L4S
> >>>>> behaviors and "burning" the last ECT codepoint. Personally, I like
> >>>>> concepts with a little bit more potential to be useful for future
> >>>>> development (evolvability) of congestion controls, e.g., BBRv2 and
> >>>>> LoLa could also benefit from an SCE-like marking...
> >>>>>
> [BB] BBRv2 has not used SCE, but it has used L4S marking. And the
> authors of the LoLa draft have not used SCE but they have merged with
> the NQB draft, so that they can work with L4S as well. So perhaps your
> belief that SCE is "more evolvable" is just that - a belief.
> 
> 
> >> This last sentence... please really spell it out what you could possibly
> >> be meaning here. What has made you suddenly think this particular
> >> marking scheme has got magical properties that bestow evolvability? I'm
> >> serious, if you can't explain why you've said a sentence like this, it
> >> implies you are under the spell of some cult or fad.
> > Not sure what you are trying to indicate by your last sentence, but
> > sure, I can elaborate a bit on my last sentence.
> > I find it architecturally cleaner to have an additional ECN codepoint
> > used for indicating "SCE" rather than (ab)using it as classifier for the
> > dualQ AQM.
> [BB] I just forked another thread 'ECN as a classifier' to address that
> assertion.
> > The SCE markings can be used independently whether you have multiple
> > queues or just a single queue.
> [BB] This seems to be the opposite of reality. Perhaps you've used the
> word 'can' because you think it might be possible. But there's good
> reason to doubt that. As follows...
> 
> Packets from non-SCE and from SCE senders are indistinguishable by just
> looking at them. So, if there's a single queue, they have to be mixed
> together in it {Note 1}. But a single queue can only have one length.
> Any transports that don't understand SCE drive the single queue to a
> deeper operating point (defined by CE or drop). This overruns the SCE
> operating point, and causes SCE marking to approach 100% {Note 2}. Then
> those transports that do understand SCE will starve.
> 
> In contrast, L4S works in dual queues or multiple queues (where 'works'
> means it gives very low latency without losing utilization).
> 
> Also, there is considerable scope for evolvability with both:
> * the dualQ is a framework that is intended to encompass different AQMs
> in future.
> * and there is considerable scope for developing the ways FQ uses L4S.
> 
> {Note 1}: Unless L4 identifiers are used to separate out microflows, and
> identify low latency flows by their behaviour. But then it's not really
> a single queue, unless you make it look like a single queue, but still
> treat it like multiple queues, as in LFQ. However, schemes like LFQ are
> "single-queue" in name only. They still have all the downsides of
> multiple queues.
> 
> {Note 2}: Unless the SCE operating point is hardly any shallower than
> that for CE, in which case SCE gives hardly any improvement.
> 
> > If one leaves the coupling aside the
> > algorithm for marking will probably not differ so much from what is
> > proposed in L4S.
> [BB] You still haven't explained (rather than asserted a belief) why the
> choice between SCE and L4S has anything to do with evolvability.
> 
> >>>> My whole purpose in solving the problem of deploying scalable CCs
> over
> >>>> the Internet was to re-juvenate evolution (to widen the range of
> >>>> applications that could be supported by different transport behaviours,
> >>>> particularly for real-time with low latency and high throughput at the
> >>>> same time). One of the main things that has stopped CCs evolving so
> far
> >>>> is the need for friendliness with the Reno behaviour that was not
> >>>> scaling over the years.
> >>> FWIW, our delay-based approach has deployment problems at the
> >>> other end of the spectrum: it gets suppressed by loss-based CCs...
> >>> (and we don't want to sacrifice our low delay goal).
> >>>
> >>>> If SCE is primarily supported in FQ AQMs, that will constrain flows to
> >>>> be capped at the rate that FQ gives them. How is that doing anything
> >>> I was solely referring to the marking behavior of SCE, not a particular
> >>> implementation based on FQ-AQMs.
> >> This implies you believe all that silliness about a shallower SCE
> >> threshold not starving an SCE flow in a single queue, because it makes
> >> SCE flows not want to use the queue.
> > I do not understand what you are saying here.
> [BB] I've now explained this above (after "But there's good reason to
> doubt that...").
> 
> The silliness I'm referring to is the statement by Jonathan M in his
> tsvwg talk at IETF-106 that CNQ is backward compatible with RFC3168
> traffic, because its performance for SCE traffic when mixed with 3168 is
> bad enough that it discourages use of SCE alongside 3168.
> 
> >>>> other than massively constraining future evolution of CCs, especially
> >>>> real-time ones? See Per-Flow Scheduling and the End-to-End
> Argument
> >>>> <http://bobbriscoe.net/projects/latency/per-flow_tr.pdf>. I don't
> need
> >>>> to tell you that the e2e argument is all about giving end systems the
> >>>> power to innovate without permission.
> >>>> Anyway, what are you imagining would stop CCs evolving alongside
> other
> >>>> scalable CCs? In much the same way CCs have always evolved. With L4S
> you
> >>>> have a clean slate that seems just like a FIFO with a shallow ECN-only
> >>>> immediate AQM. And other flows are causing you hardly any delay and
> very
> >>>> rarely any loss. Think of all the things you can do with that. Go
> >>>> evolve, Roland!
> >>> I already said that the Dual Queue AQM is nice, but comes with the
> >>> problem due to its built-in dropping law. Other CCs may react differently
> >>> and BBR was one example of newer CCs that did not work in the L4S
> queue
> >>> without further adaptation.
> >> The built in dropping law is for the old traffic ('pre-evolved' if you
> >> like) that doesn't respond to anything else but loss. That's what
> >> drop-based AQMs were for - to fool Reno etc into thinking they had hit
> >> the buffers, so to speak.
> > Yes, I understand that. But what happens if the classic traffic
> > once vanishes and we only have low-delay congestion control and
> > want to re-use the "second" queue for other purposes, e.g., using
> > it for flows that do not use loss-based CC?
> [BB] Let me repeat back the question, 'cos it seems rather odd, so
> perhaps I've misunderstood.
> 
> You want me to assume that the classic behaviour of repeatedly seeking
> out more capacity until loss occurs doesn't exist on the Internet any
> more. There's only low-delay CC, by which I think you mean CC based on
> L4S ECN (but I'm not sure that's your meaning).
> 
> Then, it sounds like everything would be working well. So why do you
> want to re-use the "second" queue for other purposes? Nothing is wasted
> if you don't use it. It has no capacity associated with it. it's just
> some lines of code sitting there in case packets appear from a classic CC.
> 
> 
> >>>    > The key thing here is the wording of the Prague requirements
> >>>> <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#section-4>.
> >>>> We have a session in the 'Prague' side-meeting tomorrow to review
> them
> >>>> (and I encourage this on this list too).
> >>>>
> >>>> Later down the line, if the L4S experiment is successful, there will be
> >>>> an opportunity to review these requirements if a standards track doc
> >>>> replaces the experimental (it is easier to relax CC requirements than
> >>>> tighten them). So, for the expt track, the requirements are designed to
> >>>> protect competing flows from harm in a tighter way than you might find
> >>>> in RFC5033 or similar.
> >>>>
> >>>>
> >>>> Nonetheless, even the 1/p isn't tightly spec'd, quoting:
> >>>>
> >>>>      The inverse proportionality requirement above is worded
> >>>>      as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
> >>>>      when defining these specifications.
> >>> Yes, but something has to be implemented (in hardware) and therefore
> it
> >>> is fixed for some time and it should be consistent along a path, so I
> >>> don't see a viable path for evolvement of this coupling law...
> >> Why does the coupling law need to evolve? It's a relationship between
> >> something invariant (scalable) and the past (which is over, by
> >> definition, so it's not going to change now).
> > See above, probably we want to put something into queue which is
> > using a non-loss-based congestion control and/or we need to change
> > the (1/p,1/p^2) marking.
> [BB] The queue doesn't induce loss, the CC does. The queue isn't 1/p or
> 1/p^2 or whatever, the different CCs are. So, if a CC is using the C
> queue without inducing any loss (e.g. a delay-based CC might be able to
> keep the queue under the AQM's target delay), then the coupling won't
> couple any marking across to the L queue.
> 
> But I can't imagine why a delay-based CC that can keep the queue below
> the target of the AQM would want to classify itself into a queue
> designed for CCs that need to induce a decent queue (in order to
> maintain full utilization), given such queue-inducing traffic might
> start up at any time.
> 
> >> If you want to evolve, you select what's best for you - probably the
> >> nice clean L4S ECN queue. I still don't get what sort of evolution you
> >> can't do? Evolvability isn't about a researcher being able to do what
> >> they'd like.
> > I also don't understand it in this way, but investigating
> > invariables and degrees of freedom prudently may enable or facilitate
> > deployment of new stuff. If that new stuff cannot be deployed
> > it never gets a chance of being weeded out later either.
> [BB] If you have something specific in mind, please say it. This is all
> getting rather abstract.
> 
> This does make me want to question your notion of evolvability. Usually,
> when we make sure the Internet supports evolvability, we mean
> evolvability of new applications. We don't mean the ability for
> researchers to come up with different ways to solve problems that are
> already solved. There seems to be a hint of a complaint in your emails
> that L4S doesn't leave room for researchers to solve the same problem
> differently. That sort of evolvability is rather a luxury isn't it? If
> one approach solves an enduring problem with the Internet, it would be
> rather churlish to say "No, we can't use this solution, because it might
> preclude some ideas that might lead to other solutions to the same
> problem in the future, but we're not sure."
> 
> Having said that, I hope I (and Koen) have shown that L4S still leaves
> scope for complementary delay-based CCs, not to mention scope for
> different AQMs and for different FQ-based solutions.
> 
> 
> Regards
> 
> 
> 
> Bob
> 
> 
> 
> >
> > Roland
> >
> 
> --
> __________________________________________________________
> ______
> Bob Briscoehttp://bobbriscoe.net/